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Capability and Quality-of- Service 
Negotiations and Session Establishment for 
Distributed Multimedia Applications 



The underlying invention generally relates to the field of 
mobile computing in a wireless mobile networking environment 
with distributed multimedia applications and technologies. 
More specifically, it is directed to the field of Quality-of- 
Service (QoS) management for adaptive real-time services run- 
ning on mobile devices which support different access tech- 
nologies in dynamic wireless Internet Protocol. (IP) networks, 
thereby including research and development issues which are 
especially related to multimedia middleware and resource res- 
ervation mechanisms . 

A problem that mobile users will most likely face is how to 
cope with limited resources at the end systems and in the 
network, and unstable environment conditions. Mobile users 
are in- fact expected to incur more frequently on the unfortu- 
nate case of having their QoS Contracts being no longer sup- 
ported by the network infrastructure, due to various reasons 
like wireless link quality degradations, horizontal and/or 
vertical handovers, limited amount of mobile terminal re- 
sources, etc., which shall be referred to as „QoS viola- 
tions". By assuming proper resource overprovision in the 
backbone, it can be expected that QoS violations will most 
likely originate in the access network, especially in the ra- 
dio part thereof. 

Furthermore, mobile multimedia applications dealing with mul- 
tiple media streams of information being simultaneously ex- 
changed with a multiplicity of peers require an effective and 
efficient way of negotiating capabilities and handling QoS 
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requirements, especially in view of the aforementioned unsta- 
ble environment conditions. 

A possible way of coping with unstable environment conditions 
5 is to enable the mobile users' applications to efficiently 

and timely react to QoS violations. Peers can in fact negoti- 
ate off-line various alternative QoS Contracts at different 
levels of abstraction, so that at the time when a connection 
is established and whenever QoS violations occur, agreements 
10 on how to most effectively adapt to the mutated conditions 
can timely be accomplished among the peers. 

BRIEF DESCRIPTION OF THE PRESENT STATE OF THE ART 

15 In the European patent application EP 01 122 366.6, the End- 
to-End Negotiation Protocol (E2ENP) has already been intro- 
duced and described in detail. As the present invention de- 
velops further the ideas described in this European- Patent 
application, its disclosure is hereby incorporated by refer- 

20 ence . 

The following table gives a brief overview of recently pub- 
lished articles which describe the concept of QoS negotiation 
protocols (in alphabetical order) : 



Abbr. 


Publication 


[Ber] 


T. Berners-Lee et al.: ^Uniform Resource Identi- 
fiers (URI) : Generic Syntax Networking Working 
Group, Standards Track RFC 2396. 


[Bosl] 


L. Bos et al.: „A Framework for End-to-End User 
Perceived Quality of Service Negotiation", IETF 
Internet Draft, work in progress, <draft-bos- 
mmusic-sdpqos-framework-OO.txt>. It describes a 
process for negotiating QoS with SIP and SDP be- 
tween two peers. However, it does not describe 
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. Abbr. 


Publication 1 1 




any architecture . for the entity using this proc- 
ess . 


[Bos2] 

* 


L. Bos et al.: „SDPng Extensions for Quality-of- 
Service Negotiation", IETF Internet Draft, work 
in progress, <draf t-bos-mmusic-sdoncr-aoe:- 
OO.txt>. It describes a process for negotiating 
QoS with SIP and SDP between two peers. However, 
it does not describe any software architecture 
for the entity using this process. 1 


[BRAIN] 


„Concepts for Service Adaptation, Scalability 
and QoS Handling on Mobility-Enabled Networks", 
IST-1999-10050 BRAN Deliverable 1.2 
(http://www.ist-brain.org/). | 


[BRENTA] 


A. Kassler et al.: ,,BRENTA - Snnnnr-t- -i nrr MnK-; i ,• 4-. .1 

and Quality of Service for Adaptable Multimedia , 
Communication", in: Proceedings of the 1ST Mo- 
bile Communications Summit 2000, Galway, Ire- 1 
land, October 2000, pp. 403-4O8. 


[Caml] 


G. Camanllo, W. Marshall, J. Rosenberg: 

integration of Resource Management and SIP", 
IETF Internet Draft, work in progress, <draft- 
ietf-sip-manyfolks-resource-07.txt>. It develops 
the requirements of an „0ffer/ Answer MnHoi" 
based on SDP, also in the sense of reservation. 
However, it does not describe any software ar- 
chitecture for the entity performing such srie- 
cific negotiations. -• 


[Cam2] 


G. Camanllo et al. : „Grouping of Media Lines in 
SDP" (IETF Internet Draft, work in progress, 
<draft-ietf-mmusic-fid-04.txt>) . | 


[Gam] 


E. Gamma et al.: „Design Patterns - Elements of 
Reusable Object-Oriented Software", Addison- 
Wesley, Reading-Massachusetts (USA), 1994. ( 
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Abbr. 


Publication 


[Gu] 


X. Gu, 'K. Nahrstedt et al.: „An XML-based Qual- 
ity-of-Service-Enabling Language for the Web", 
Project Report of the National Science Founda- 
tion, 2001. 


r rzitoi 

L oUc J 


T Riipnkovv- Liiv. A Kassler. J Eisl. T) . Man— 
dato: ^Efficient End-to-End QoS Signaling - Con- 
cepts and Features", IETF Internet Draft/ work 
in progress, <draf t-guenkova-mmusic-e2enp-sdpng- 
pq.txt>. 


[Klyl] 


G. Klyne: „A Syntax for Describing Media Feature 
Sets", IETF RFC 2533. 


[Kly2] 


G. Klyne: ^Identifying Composite Media Fea- 
tures", IETF RFC 2938. It describes an optimiza- 
tion for the algorithm disclosed in [Klyl] by 


[Kutl] 


D. Kutscher et al . : ^Requirements for Session 
Description and Capability Negotiation" (IETF 

x 11 LCi.iiC L> xvx, a x. / w\jj. jv J.11 x. v-/ y i coo / ^ul ai. u 

kutscher-mmusic-sdpng-req-01 . txt>) . 


[Kut2 ] 


D. Kutscher "et al * : ^Session Description and Ca- 
pability Negotiation", IETF Internet Draft, work 
in progress, <draf t-ietf-mmusic-sdpng-04 . txt>. 


[Manl ] 


D. Mandato, A. Kassler, T. Robles/ G. Neureiter: 
^Concepts for Service Adaptation, Scalability 
and QoS Concepts on Mobility-Enabled Networks" 
/TST Global Summit* 2001. Barcelona. Seotember 
2001, pp. 285-293) . This article describes the 
core concepts of the End-to-End Negotiation Pro- 
tocol (E2ENP) . A similar paper has been pre- 
sented at PIMRC 2001 in San Diego, October 2001. 


[Man2] 


D. Mandato, A. Kassler, T. Robles and G. Neure- 
iter: ^Handling End-to-End QoS in Mobile Hetero- 
geneous Networking Environments" (PIMRC 2001, 
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Abbr. 


Publication 




San Diego, -30/9/~2001 to - 3/10/2001, pp. C-49 to 
C-54) 


[ReqSpec] 


„End-to-End Negotiation Protocol", IST-2000- 
28584/ 

SO/WPl/PI/I/003/al, MIND Internal Contribution 
to WP1, Activity 1.3 , Work Item 2. 


[Rosl] 


J. Rosenberg, H. Schulzrinne et al.:: „SIP: Ses- 
sion Initiation Protocol", IETF Standards Track, 
Network Working Group, RFC 3261, This document 
describes the Session Initiation Protocol (SIP) , 
which is an application-layer control 
(signaling) protocol for creating, modifying and 
terminating sessions with one or more partici- 
pants . 


[Ros2] 


J. Rosenberg, H. Schulzrinne: „An Offer/Answer 
Model with SDP", IETF Internet Draft, work in 
progress, <draf t-ietf-mmusic-sdp-of f er-answer- 
02,txt>. This document defines a mechanism by 
which two entities can make use of SDP to pro- 
vide a common view of a multimedia session be- 
tween them. 



[Caml] presents a multi-phase call-setup mechanism that makes 
network QoS and security establishment a precondition to ses- 
sions initiated by the Session Initiation Protocol (SIP) and 
5 described by the Session Description Protocol (SDP) . Network 
resources are reserved before the session is started, thereby 
using existing network resource reservation mechanisms (e.g. 
RSVP) . 

0 [Klyl] presents a format to express media feature sets that 
represent media handling capabilities. In addition, an algo- 
rithm is provided that matches the feature sets. It might be 
used to determine if the capabilities of a sender and re- 



P 26921 EP and P 26922 EP 



6 



ceiver are compatible. In addition, in [Kly2] an abbreviated 
format for composite media feature. sets that use a hash .of . 
the feature representation to describe the composite is dis- 
closed. 

5 

In [Ros2], a complete model for a one-to-one capabilities ne- 
gotiation with SDP is described. However, this model suffers 
from problems caused by the definition of mutually referred 
information and information on grouping media streams due to 
10 the flat hierarchy structure of the SDP. 

[Kutl] describes a set of requirements relevant for a frame- 
work for a session description and an endrpoint capability 
negotiation in multi-party multimedia conferencing scenarios. 
. 15 Depending on user preferences, system capabilities or other 
constraints, different configurations can be chosen for the 
conference. Thereby, the need for a negotiation process among 
the peers is identified, but not described in order to deter- 
mine a common set of potential configurations and select one 

20 of the common configurations to be used for information ex- 
change. This capability negotiation is used to get t a valid 
session description, compatible with the end system capabili- 
ties and user preferences of the potential participants. Dif- 
ferent negotiation policies may be used to reflect different 

25 conference types. They also identify the need for network re- 
source reservation coupled with session setup. Finally, a 
proposal is drafted for describing capabilities and providing 
the. -negotiation, .language, but not a. protocol. Thereby, the 
solution proposed in [Kutl] does neither consider the nego- 

30 tiation protocol for determining a common set of QoS configu- 
ration nor integrate local, peer and network resource reser- 
vation. 

The most recent version of this IETF draft, in the following 
35 referred to as [Kut2] , provides a detailed XML Schema speci- 
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fication and a prototype of the Audio Codec and Real-Time 
Protocol (RTP) Profiles . 

In [Bosl], an end-to-end user-perceived QoS negotiation is 
5 described, with the presumption that some intermediate compo- 
nents and services may strongly be involved in the final de- 
cision about the negotiated QoS-information of the end peers. 
The decision as described may be taken over some standard 
„contract types". Although it is mentioned that the signaling 

10 and the data path may go different ways through the network, 
it is suggested that some intermediate components on the way- 
of the negotiation path may influence the negotiation though 
in general having nothing to do with the data paths. In case 
this protocol model is deployed, the network is not transpar- 

15 ent. The negotiation process according to [Bosl] is performed 
at one shot interleaving also with some non-QoS information 
(e.g. security, network admittance, etc.) without considering 
protocol modularity and information consistency with respect 
to QoS . With the model of [Bosl], it is only possible to use 

20 a push mode for the negotiation, which may be restrictive for 
some applications and services. The adaptation paths are only 
degrading and fixed. 

In the articles [Manl], [Man2], and [Cam2] , the possibility : 
25 of grouping media streams is discussed. However, the authors 
do not consider criteria for the grouping, the possibility of 
recursive group building (a group of many groups), and the 
treatment of real, pseudo-real and non-real-time information 
media streams that also may be grouped. Besides, [Manl]. and 
30 [Man2] define negotiation steps that may or may not run at 
one shot but not during independent negotiation phases. For 
this reason, they do not meet the requirements for the con- 
sistency of the negotiated QoS information during a negotia- 
tion phase and after it. Thereby, in [Manl] the core concepts 
35 of the E2ENP are disclosed. The treatment of colliding „Econ- 
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omy Principle" applications is also not considered. Moreover, 
[Manl] and [Man2] describe the possibility of setting and 
managing adaptation paths for the QoS adaptation, which is 
controlled by a third party component - the QoS Broker. How- 
ever, the authors do not consider any possibility for the end 
parties to perform and control the negotiations on their own. 

PROBLEMS TO BE SOLVED BY THE INVENTION 

Nowadays, adaptive applications and/or middleware (e.g.. QoS 
Brokers) do not comprise any component which is capable of 
handling QoS pre-negotiation, QoS negotiation, QoS re-nego- 
tiation, resource reservation and/or release coordination of- 
fering a technology-independent Application Programming In- 
terface (API), which masks the type of signaling protocols 
used for implementing those mechanisms. Instead, adaptive 
multi-stream multimedia applications and/or middleware have 
directly to be coded against protocols like H.323, the Ses- 
sion Initiation Protocol (SIP) and/or the Session Description 
Protocol (SDP, in future SDPng as described in [Kut2J). Fur- 
thermore, said SIP- and/or SDP-based applications or middle- 
ware directly perform a parsing of the SDP data and have to 
infer the actions to be taken by examining changes on the SDP 
data from previously exchanged versions thereof. 

Another problem is that adaptive applications and/or middle- 
ware (e.g. QoS Brokers) are not able to express the informa- 
tion, to be negotiated • (e.g-. capabilities,- application-level 
QoS Contracts, network-level QoS Contracts, stream-level ad- 
aptation paths, and stream-group-level adaptation paths) in 
an interchangeable format. It is required that heterogeneous 
applications and/or middleware can easily agree on a refer- 
ence model, which said applications and/or said middleware 
can then use for dynamically configuring themselves to or- 
chestrate local, peer, and network resources according to the 
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preferences and profiles of the respective user, policies of 
the respective systems and- network providers in a coordinated 
manner among a multiplicity of heterogeneous applications and 
middleware used by various peers. 

In the European patent application EP 01 122 366.6, the over- 
all E2ENP concept, its requirements, and a possible implemen- 
tation idea thereof is disclosed, however, without detailing 
any implementation. Any pre-negotiated information is not ac- 
complished in time. 

Although the current form of SDPng as described in [Kut2] is 
structured in a modular way, it does not consider E2ENP as- 
pects and can not be used in a modular way across different .- 
SIP messages (or other protocol messages) . Capability nego- • 
tiations based on SDPng use the SDP Offerer/Answerer model, 
in which complex multi-phase negotiation processes such as 
the one proposed in the scope of E2ENP are not explicitly 
taken into account. 

A process capable of considering user profile information as 
input for the overall QoS negotiation process is neither ad- 
dressed in the European patent application EP 01 122 366.6 
nor in SDPng. 

OBJECT OF THE UNDERLYING INVENTION 

In view of the explanations mentioned above, it is the pri- 
mary object of the underlying invention to propose a negotia- 
tion method and a software architecture supporting capability 
and QoS negotiation and session establishment combined with 
resource reservation mechanisms for adaptive real-time serv- 
ices and multimedia applications. 
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This object is achieved by means of the features of the inde- 
pendent claims. Advantageous features are defined in the sub- 
ordinate claims- Further objects and advantages of the inven- 
tion are apparent in the following detailed description, 

5 

SUMMARY OF THE UNDERLYING INVENTION 

The underlying invention is basically dedicated to the con- 
cept and realization of a novel User Agent (UA) for an End- 

10 to-End Negotiation Protocol (E2ENP) - a software module en- 
capsulating the end-to-end signaling processes of the E2ENP . 
as described in [ReqSpec] -, which can advantageously be ap- 
plied to define user profile and terminal capability informa- 
tion in such a way that hierarchical QoS Contract specif ica- 

15 tions (e.g. compelling correlations across different sets of 
QoS Contracts for related media streams) can be enforced and 
used for deriving negotiable information. As a reference im- 
plementation of this concept, this invention describes a 
novel usage of the Session Initiation Protocol (SIP) stan- 

20 dardized by the Internet Engineering Task Force (IETF) in 

- conjunction- with extensions of -the Session Description Proto- 
col - Next Generation (SDPng) specification based on the Ex- 
tensible Markup Language (XML) in order to implement End-to- 
End QoS Negotiation Protocol (E2ENP) concepts. More specif i- 

25 cally, the hereby proposed mofiel extends the SDPng negotia-. 
tion mechanisms by defining user profile and terminal capa- 
bility information which allow to enforce and use hierarchi- 
• -cal QoS Contract; specifications v • •• .... 

30 Thereby, said End-to-End Negotiation Protocol (E2ENP) is ap- 
plied to derive negotiable information, which enables a pre- 
negotiation, fast negotiation and a fast, dynamic re-negotia- 
tion of the end-to-end quality and capabilities for a tele- 
communication session, for multiple configurations of two or 

35 a multiplicity of end peers and/or intermediate components in 
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a' consistent, reliable;, and incremental way by enabling the 
mobile applications to. efficiently and timely react to QoS 
violations. Furthermore/ the invention pertains to the con- 
cept and realization of a novel E2ENP User Agent which encap- 
5 sulates the signaling part of E2ENP. Said E2ENP User Agent 
expresses the information to be negotiated in an interchange- 
able format in such a way that heterogeneous applications can 
easily agree on a reference model, which can then be used for 
dynamically configuring Finite State Machines to orchestrate . 
10 local, peer, and network resources according to the prefer- 
ences and profiles of the respective user in a coordinated 
manner. 

According to the underlying invention, the conversation of an 

15 interchangeable format between an internal (application- and/ 
or middleware-specific) and an external (SIP User Agent spe- 
cific) representation is performed by a Parser and a Factory 
implementation. These software components are also configur- 
able according to the specific needs of the underlying car- 

20 rier protocol agent, the E2ENP User Agent, and the respective 
application and/or middleware. In this connection, the spe- 
cific. E2ENP User Agent session identification and the respec- 
tive application and/or middleware session identification of 
the applied negotiation processes and sub-processes are 

25 uniquely mapped to each other and cached in order to be able 
to uniquely identify pre-negotiation, negotiation and/or re- 
negotiation sessions. Thereby, the Parser, .the Factory, and 
the Cache are coupled with the implementations of the respec- 
tive E2ENP User Agent. It should be noted that the configura- 

30 tion of these four software components - Parser, Factory, 
Cache, and E2ENP User Agent - and the User Agent of the ap- 
plied carrier protocol is an application-specific task, which 
depends on the needs of the respectively employed application 
and/or middleware component . 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Further advantages and possible applications of the underly- 
ing invention result from the subordinate claims as well as 
from the following description of the preferred embodiment of 
the invention, illustrated by the following figures and ta- 
bles: 

Fig. 1 presents a block diagram showing the applied. architec- 
ture for the User Agent (UA) of the End-to-End Negotia- 
tion Protocol (E2ENP) according* to the underlying inven- 
■ tion, 

Fig. 2 shows a first implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using a Java-based SIP stack 
( JSIP) , an SDPhg Parser and Factory, 

Fig. 3 shows a second implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
■ ' gotiation Protocol- (E2ENP) according to one embodiment 
of the underlying invention using Sun's Java Remote 
Method Invocation (RMI) , 

Fig. 4 shows a third implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment 
of the underlying- invention using the socked-based User 

<- — • - Datagram' Protocol (UDP) or Transmission Control Protocol 
(TCP), 

Fig. 5 exhibits a UML class diagram showing the 
org: rmind: : e2enp package, 

Fig. 5 bls shows the E2ENP Management API between the E2ENP UA Fac- 
tory and the management entities, 

Fig. 6 presents a document showing examples for the syntax of 
the E2ENP Universal Resource Identifier (URL), thereby 
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using the Augmented Backus-Naur Form (ABNF) , 
Fig. 7 outlines a first message sequence chart (MSC) showing 

the pre-negotiation procedure enabled by the User Agent 
(UA) of the proposed End-to-End Negotiation Protocol 
(E2ENP) , 

Fig. 8 outlines a second message sequence chart (MSC) showing 

the session establishment with a QoS negotiation and re- 
source reservation coordination enabled by the User 
Agent (UA) of the proposed End-to-End Negotiation Proto- 
col (E2ENP) , 

Fig. 9 exhibits a UML class diagram showing the 
org: : mind: :e2enp: : Cache sub-package, 

Fig. 10 presents a diagram showing the top-level view of an Ex- 
tensible Markup Language (XML) description used for the 
End-to-End Negotiation Protocol (E2ENP) , 

Fig. 11 presents a diagram showing the XML substitution groups 
used for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 12 presents a diagram showing the XML purpose element used, 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 13 presents a diagram showing the XML qosdef element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 14 presents a diagram showing the XML qoscfg element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 15 exhibits a UML message sequence chart (MSC) showing the 
interaction between the E2ENP User Agent (E2ENP UA) ; ac- 
cording to the underlying invention and the applied 
Parser and Cache, 

Fig. 17 exhibits a UML class diagram showing the general struc- 
ture of a Document Object Model (DOM) tree, 

Fig. 18 exhibits a UML class diagram showing a structural over- 
view of the Parser implementation using a visitor design 
pattern, 

Fig. 19 presents a UML message sequence chart (MSC) showing the 
interaction between the E2ENP User Agent (E2ENP UA) ac- 
cording to the underlying invention and the applied Fac- 



P 26921 EP and P 26922 EP 

14 



tory and Cache, 

Fig. 20 presents a UML class diagram showing a structural over- 
view of the Factory implementation, 

Fig. 21 exhibits a UML class diagram showing the 
org: : mind: : sip: :sipApi package. 

Fig. 22 exhibits a UML class diagram showing the 

org: :mind: :sip: :sipApi: :userAgent package, 

Fig. 23 exhibits a UML class diagram showing the 

org: :mind: : sip: : sipApi :: registrar package, 
t _Fig._ 2.4 exhibits a UML class, diagram .showing the 

org: : mind: : sip: :sipApi: management package, 

Fig. 25 exhibits a UML class diagram showing the 
org: :mind: : sip: :sipApi: : time package, 

Fig. 26 exhibits a UML message sequence chart (MSC) showing the 
configuration of the Service Provider and the binding of 
the Service User with said Service Provider, 

Fig. 27 exhibits a UML message sequence chart (MSC) showing the 
connection establishment between the User Agents of a 
client and a server, 

Fig. 28 exhibits a UML message sequence chart (MSC) showing the 
• - • OPTIONS method used for the End-to-End Negotiation Pro- 
tocol (E2ENP) , 

Fig. 29 exhibits a UML message sequence chart (MSC) showing the 
connection release between the User Agents of a client 
and a server, 

Fig. 30 shows a first state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mut ex-related pro- 
■ cedures executed in the root state, 

Fig. 31 shows a second state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
• cedures executed in the NegOf f erer sub-state, 

Fig. 32 shows a third state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the NegAnswerer sub-state, 

Fig. 33 shows a fourth state transition diagram- for a nested Fi- 
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nite State Machine (FSM) showing the mutex-related pro- 
cedures executed, in the HeNegOf ferer sub- state, 
Fig. 34 shows a fifth state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the ReNegAnswerer sub-state, 
Fig. 35 shows a sixth state transition diagram for the „_Resv- 
Mtx* Finite State Machine (FSM) for allowing multiple 
requests to seize the mutex in a coordinated manner, 
based on their priority, 
Fig. 36 shows a seventh state transition diagram for a nested 
Finite State Machine (FSM) showing the mutex-related 
procedures executed in the WaitForCoordDone sub-state, 
Fig. 37 exhibits a UML message sequence chart (MSC) showing the 
pre-negotiation procedure needed for the correlation of 
the Application Programming Interface (API) of the E2ENP 
User Agent (E2ENP UA) and the generic Application Pro- 
gramming Interface (API) of the SIP User Agent (SIP UA) , 
thereby using the above-mentioned Finite State Machine 
(FSM) of the E2ENP User Agent (E2ENP UA) , 
Fig. 38 exhibits a UML message sequence chart (MSC) showing the 
session establishment with the QoS negotiation procedure- 
and the resource reservation coordination needed for the 
correlation of the Application Programming Interface 
(API) of the E2ENP user Agent (E2ENP UA) and the generic 
Application Programming Interface (API) of the SIP User 
Agent (SIP UA) , thereby using the above-mentioned Finite 
State Machine (FSM) of the E2ENP User Agent (E2ENP UA) , 
Tab. 1 shows a" list of primitives implemented by the Service 

Provider, based on a Java implementation of the Applica- 
tion Programming Interface (API) applied to the User 
Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 2 shows a list of primitives to be implemented by the 

Service User, based on a Java implementation of the Ap- 
plication Programming Interface (API) applied to the 
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User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , - - • - • - . ...... 

Tab- 3 shows a list of primitives to be implemented by the 

Service User acting as an Offerer, based on a Java im- 
plementation of the Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab- 4 shows a list of primitives to be implemented by the 

Service User acting as an Answerer, based on a Java im- 
plementation Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab. 5 shows the methods provided by the Application Program- 
ming Interface (API) of the first Cache level* 

Tab. 6 shows the methods provided by the Application Program- 
ming Interface (API) of the second Cache level. 

Tab. 7 shows a list of primitives which have to be implemented 
by the Application* Programming Interface (API) of the 
Parser, .... 

Tab. 8 shows a list of primitives which have to be implemented 
• - for generating -a- specific Parser instance, 

Tab. 9 shows a list of primitives which have to be implemented 
by the Application Programming Interface (API) of the 
Factory/ 

Tab. 10 shows a list of primitives which have to be implemented 
for generating a specific Factory instance, 

Tab. 11 shows the methods provided by the well-known Factory- 
Factory -class E2ENPContentHandlerFactory, 

Tab. 12 shows a list of primitives implemented by the Service 

Provider, based on a Java implementation of the generic 
Application Programming Interface (API) applied to the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 13 shows a list of client-side-specific primitives imple- 
mented by the Service User, based on a Java implementa- 
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tion of the generic Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab. 14 shows a list of server-side-specific primitives imple- 
mented by the Service User, based on a Java implementa- 
tion of the generic Application Programming Interface 
(API) applied to the User Agent (UA) of the End- to- End 
Negotiation Protocol (E2ENP) , 

Tab. 15 shows a list of both client-side- and server-side- . 

specific primitives implemented by the Service User, 
based on a Java implementation of the generic Applica- 
tion Programming Interface (API) applied to the User 
Agent (UA) of the End-to-End Negotiation Protocol* 
(E2ENP) , 

Tab. 16 shows a list of primitives implemented by the Service 

Provider, based on a Java implementation of the generic 
Application Programming Interface (API) applied to the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 17 shows a list of primitives implemented by the Service 

User, based on a Java implementation of the generic Ap- 
plication Programming Interface (API) applied to the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 18 is a state transition table showing a survey of the ap- 
plied exception events, and 

Tab. 19 shows the applied timers applied to the End-to-End Ne go 
tiation Protocol (E2ENP) according to the underlying in 
vent ion. 
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DETAILED DESCRIPTION OF THE UNDERLYING INVENTION 

According to one embodiment of the underlying invention, a 
5 E2ENP UA 128 supports the following platforms: Win32 and 
Linux. Quality, robustness, maintainability, extensibility, 
flexibility and efficiency are the challenges to the archi- 
tecture and its solutions. 

.10 - Quality includes testability and verification of the . system 
already during development. Robustness is the ability of 
the system to stay stable and available also in error 
situations. Both aims directly affect the availability and 
acceptance of the system. 

15 ' 

- Maintainability and extensibility include all costs of the 
system in later phases (concerning both error correction 
and extensions) . These costs must be minimized. 

20 - Flexibility also addresses the point that changes should be 
applied as cost-effective as possible. 

- Efficiency addresses minimization of resource usage (con- 
cerning memory and processor) . 

25 

For the architecture, the following basic conceptual and 
technical requirements can be derived: 

♦ definition of design components with well chosen and de- 
30 fined responsibility and features; 

♦ small dependencies between design components (loose cou- 
pling) , so that changes have only a limited effect; 

♦ minimum resource consumption, especially concerning the 
applied Random Access Memories (RAMs) ; 
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♦ a strict separation between interface and implementation 
(a change of the implementation shall not affect the in- 
terface) ; 

♦ definition of restrictions, if this simplifies the reali- 
zation concept - however, restrictions and their effects 
must be negotiated with the stakeholders. 



The E2ENP UA 128 depicted in Fig. 1 is designed as a software 
component which communicates with the environment through the 
following five APIs: 



• E2ENP Management API 101a (IF1) : This API represents the 
interface between the E2ENP UA 128 and any entities 102 
managing it, in the sense of configuration, monitoring, and 
control . 



• E2ENP UA API 101b (IF2) : This API represents the interface 
between the E2ENP UA 128 and any application 130 or middle- 
ware using the services offered by said E2ENP UA 128. The 
information exchanged through this API can.be modeled as an 
object structure or as an XML-based document, to be accord- 
ingly interpreted by applications 130 or middleware 130 
placed on top of the E2ENP UA 128. 



• SIP UA Generic API 101c (IF3) : This API represents the in- 
terface between the E2ENP UA 128 and the session-layer pro- 
tocol .used for implementing the E2ENP-specif ication. The 
name of this API clearly indicates that the Session Initia- 
tion Protocol (SIP) [Rosl] is used as a reference session- 
layer protocol. However, with minor modifications, this API 
can easily be generalized in a future design review, so as 
to remove the E2ENP UA dependency on the SIP. Nevertheless, 
by using this design it would be possible to have a com- 
plete Java Remote Method Invocation (RMI) implementation of 
the SIP UA Generic API 101c (IF3) . 
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• Parser API lOld (IF4) : This API represents the interface 
between the E2ENP UA 128 and any Parser implementation 112 
used for decoding the E2ENP session description. 

5 

• Factory API lOle (IF5) : This API represents the interface 
between the E2ENP UA 128 and any Factory tool 114 used for 
encoding the E2ENP session description. 

10 Internally, the E2ENP UA 1-28 is- composed of different Finite 
State Machines 106 (FSMs) handling the coordination of the 
procedures associated with the aforementioned interfaces,, and 
their interrelations. More specifically, the E2ENP UA 128 
should feature a client FSM 106 and a server FSM 106 for iri- 

15 dependently and simultaneously handling, respectively, the 
initiation of an E2ENP (pre-) negotiation and/or session es- 
tablishment, and the response to such procedures. This means 
mapping primitives of 101b to primitives of IF3 101c, and 
vice versa. The mapping of the primitives concerns both ob- 

20 ject and object identifiers mapping. The mapped objects and 
the identifiers are stored in a respective Cache 104 at the 
E2ENP UA 128 and/or at the application 130 above IF2. 

During this mapping process, the E2ENP UA FSMs 106 should 
25 also be able to access IF4 lOld and IF5 lOle for handling, 
respectively, E2ENP session description decoding and encod- 
ing. 

The Parser 112 and Factory 114 implementation, though essen- 
30 tial entities for implementing the E2ENP concept, are de- 
signed as separated software components, insofar as they can 
be implemented in various ways (based on SDP, SDPng, SDPng- 
dialects, or any other session description languages of 
choice) . 

35 
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In the following subsection, the basic problem domains of the 
system shall be described and how they are solved within the 
E2ENP UA 128. Each problem domain is discussed individually 
and across the system. It refers to other problem domains if 
there is any interference with them or if a part of the prob- 
lem domain is discussed more detailed in an extra section. 

The E2ENP UA 128 is designed according to the object-oriented 
paradigm, and a Java-based prototype based on such design is 
hereby described. It allows using various types of XML pars- 
ing tools (through IF4) and various session level protocols, " 
(through IF3) to transport E2ENP primitives. The hereby- 
described prototype based on the aforementioned E2ENP UA de- 
sign uses SIP as described in [Rosl] as session-layer proto-r 
cols. Various SIP implementations are . supported by the E2ENP 
UA design, thanks to the abstract nature of IF3. 

In the scope of the underlying invention, both the E2ENP UA . 
FSM 106 and the SIP UA Generic API (IF3) are explicitly de- 
signed to support SIP. It is foreseen that in a future design 
review, these dependencies will be removed, by making IF3 
even more abstract. The E2ENP UA 128 will also be able to si- 
multaneously support multiple users of multiple applications 
130 using multiple instances of the E2ENP UA services. 

The E2ENP UA 128 supports three types of object categories: 
identifiers (IDs), description objects (object graphs or a 
formal description of an object graph, like XML) and event 
objects. These categories correspond to the objects passed to 
the agent through IF2, IF3, IF4, and IF5 in both directions. ■ ■ 

- The IDs are needed to uniquely identify the session de- 
scription objects. There are two types of identifiers, 
which are also objects: 
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E2ENP internal object IDs, corresponding to the objects 
processed within the E2ENP UA FSMs 106, 
• application IDs pointing also at the respective E2ENP UA 
FSM 106 objects, which are used by an application 130 to 
5 steer negotiation events. 

- The session description objects are either object graphs 
used by the E2ENP UA FSM processing or external descrip- 
tions used by the Parser 112 implementation, the Factory 

10 114 implementation,* and ~the E2ENP UA 128 "by a negotiation 
process. All these session description objects can persis- 
tently be saved by the application 130 (above IF2) using 
them. The management (leasing descriptions , refreshing of 
leased descriptions, etc.) of the saved objects is an ap- 

15 plication-specific task. 



- The event objects correspond to application; negotiation 
events, which affect the E2ENP UA FSM 106 functionality by 
triggering adaptation sequences. 

The IDs, the E2ENP UA FSM object graphs and the event objects 
are Java objects. The external protocol representations can 
be SDP, SDPng, SDPng-dialects, or any other session descrip- 
tion language objects of choice. The implementation of the 

25 Java objects passed through interface IF2 depend on the in- 
terface definition of IF2. The objects passed through the in- 
terfaces IF4 and IF5 are either E2EJJP UA FSM 106 object rep- 
resentations or external protocol representations. The ob- 
jects passed through IF3 are external protocol representa- 

30 tions. All the external representations of the session de- 
scription objects passed through IF3, IF4 and IF5 should im- 
plement java. io.Serializable in order to be compatible with 
the SIP Surrogate RMI implementation. 
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The internal representations of the session description ob- 
jects passed over the IF2, IF3, IF4 and IF5 shall be typed as 
java.lang. Object and should be cast into the expected - type by 
the E2ENP UA 128, the Parser 112, and the Factory 114. This 
requirement is necessary to keep the SIP UA 110 and the im- 
plementations of the Parser 112 and the Factory 114 modular 
by leveraging generic APIs. 

The following section contains a brief survey of the applied 
implementations of the Parser 112 and the Factory 114. 

Since the negotiation process involves at least two entities 
interconnected by a network, it is necessary to provide map- 
ping functionality from system-internal representation to a . 
transport representation over the network and back. The 
mechanisms that provide this mapping are called Parser API - 
101d (in the following referred to just as Parser 112) and 
Factory API 101e (referred to as Factory 114) ,. where the . 
Parser 112 takes an object encoded in network representation . 
as input and generates a system-internal representation of • 
said object, in contrast, the Factory 114 generates a network 
representation for a given system-internal representation. 

The need for said Parser API lOld, said Factory- API loie and 
the functionality defined by them arises from the facts that 
the system- internal representation may not be appropriate for 
a transport representation that can be sent over networks and 
the transport representation may not be adequate for a sys- 
tem-internal representation. 

Additionally, introducing these components into the system 
decouples the higher application layer from the lower trans- 
port-oriented layers. As a consequence, the actually used 
transport protocol- is of no concern to the upper application 
layers and should ideally be pluggable. 
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The use of the Extensible Markup Language (XML f as transport 
syntax is motivated by the widespread adoption of XML as an 
industry standard, and it also allows for the incorporation 
5 of external features (SDPng libraries and profiles) and pro- 
vides compatibility to related work (SDPng schema) . Another 
feature of XML is its simple extensibility. 

As described above, the use of different carrier protocols 
10 . requires that the Parser 112 and the Factory 114- are configu- 
rable by the same means as the protocol, which means that in 
case the protocol is configurable at runtime, said Parser 112 
and said Factory 114 might also have to be changed while the 
system is running. This implies the specification of an ab- 
15 stract interface, since the actual implementations depend on 
the specific underlying carrier protocols. 

Concrete Factory 114 implementations for different carrier 
protocols will produce different results. For example, an RMI 
20 factory may just be a dummy implementation. It is thus possi- 
ble to transfer Java objects, e.g. the objects „as is x \ di- 
rectly over a network connection by simply using Java Remote 
Method Invocation (RMI) . 

25 If SIP is used as a carrier protocol, however, an external 
representation (more specifically a protocol data unit or 
PDU) to be sent over the network has to be generated. Possi- 
bilities include but are not limited to some proprietary text 
format similar to SDP, for example, : or a more structured ap- 

30 proach using XML, as e.g. SDPng does. 

The API definitions for the Parser API lOld and the Factory 
API lOle are un-typed in order to support loose coupling of 
the E2ENP UA 128 and the Parser 112 as well as the Factory 
35 114. The transport representation as described above is im- 
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plemented by just using the java.io.Serializable interface, 
which is "inherently un- typed." The system-internal representa- 
tion is chosen to be the represented as java. lang. Object . The 
matching between the actual implementations of the Parser 112 
5 and the Factory 114 and the object representation used: in the 
E2ENP UA 128 have to be established by configuration. . 

The mechanism is implemented by the following two software 
components: 

10 

♦ Parser API lOld: Primitives of this API should accept as 
parameters any object implementing the java.io.Serializ- 
able interface. The result of the parsing process yields, 
an object representation according to IF2, which will ab- 

15 stractly be typed as java.lang. Object. 

♦ Factory API lOle : Primitives of this API should accept as 
parameter any object representation according to IF2, 
which will be abstractly typed as java.lang. Object and 

20 generate a representation conforming to the. 

java.io.Serializable interface. 

Additionally, in order to achieve configurability, the- use of 
a ^factory design pattern" for creating Parser 112 and' Fac- 

25 tory 114 instances is a possible solution. For this purpose, 
the factory method is parameterized with the transport proto- 
col {the distinguishing feature of different Parser 
112 /Factory 114 implementations) . If dynamic support for dif- 
ferent carrier protocols is needed, the factory classes have 

30 to provide a registration procedure for new protocols. 

In the next section, the use of SIP surrogates shall briefly 
be described. 
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The applied SIP UA Generic API 101c (IF3) requires the avail- 
ability of a SIP UA implementation' which supports such an 
API. Similarly, the Parser API lOld (IF4) and the Factory API 
lOle (F5) presume the availability of parser and factory im- 
5 plementations compatible with the UA implementation 110, re- 
spectively. In order to allow validating and rapidly proto- 
typing the E2ENP model, IF3, IF4, and IF5 have been designed 
in such a way that surrogates of real SIP UA implementations 
and of compatible Parser 112 and Factory 114 implementations 
10 . ..can.be used, as handy alternatives for.. experimental .purposes .. 

By using a legacy implementation (already provided code/API 
and/or software, possibly from an external implementer) of 
the SIP UA 110 for testing and/or updating the E2ENP UA 128, 

15 it might be sometimes difficult to establish the connection 
between the E2ENP UA 128 and the SIP UA 110, as the interface 
provided by the legacy SIP implementation may not match di- 
rectly the interface 101c required by the E2ENP UA; In gen- 
eral, using a SIP UA 110 to provide network connectivity for 

20 the E2ENP UA 128 is not recommended whenever testing new 

E2ENP UA 128 features, due to possible conceptual contradic- 
tions between the protocol agents (SIP and E2ENP) . These con- 
tradictions may result in specification changes of the car- 
rier protocol - SIP, that is why for the tests of the E2ENP 

25 UA 128 the usage of a SIP emulator (which can easily adopt 
conceptual changes) is preferable. 

In order to carry out a SIP emulation, SIP surrogates (e;g. 
Remote Procedure Call mechanisms, RPCs) can be employed. When 
30 E2ENP session description payloads have to be tested without 
necessarily using „full-blown x> Parser 112 and Factory 114 im- 
plementations, solutions coupled with the chosen SIP surro- 
gate can also be applied. 
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As mentioned above, a prototype E2ENP UA 128 implementation 
based on the hereby-presented architectural model has been 
selected for demonstrating the E2ENP concept . . Since this im- 
plementation is based on Java, an RPC-based, built-in Java 
RMI mechanism has been selected as SIP surrogate. 

Since RMI takes care of marshalling or demarshalling the SIP 
UA Generic API 101c (IF3) primitives payload directly, all 
the parameters passed to the API have to implement the java. 
io.Serializable interface. 

In order to test E2ENP session description payloads without 
necessarily using ^full-blown" Parser 112 and Factory 114 im- 
plementations (for the same reasons set forth above for the 
use of SIP surrogates), passing such content through the IF3 
as a string might be not necessary as RMI can process ob- 
jects. Rather, a whole object structure representing a given 
E2ENP session description payload might be exchanged, directly 
through the RMI marshalling or demarshalling mechanism. 
Therefore, the prototype E2ENP UA 128 implementation based on 
the hereby-presented architectural model has been designed in 
such a way that the IF3 primitives shall accept as parameters 
any object implementing the java. io.Serializable interface, 
and not just instances of the java.lang. String class: 

Said mechanism is implemented by the following software com- 
ponents : 



♦ SIP UA Generic API 101c: Primitives of this API shall ac- 
cept as parameters any object implementing the java. io.Se- 
rializable interface, and not just instances of the java. 
lang. String class. A SIP UA 110 implementation shall inter- 
pret the passed objects as instances of the java.lang. 
String class via casting mechanism. The RMI surrogate SIP 
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implementation shall directly serialize or deserialize the 
aforementioned objects „as is M . 

♦ Parser API lOld: Primitives of this API shall accept as pa- 
5 rameters any object implementing the java.io.Serializable 

interface. 

♦ Factory API lOle: Primitives of this API shall accept as 
parameters any object implementing the java. io. Serializable 

10 interface. 

Fig. 2 shows an implementation of the architectural model as 
mentioned above, based on a specific SIP UA 110 implementa- 
tion (e.g. a Java based SIP stack - JSIP) , and on Factory 114 

15 and Parser 112 implementations handling a modified version of 

»■ • - . 

SDPng . 

Fig. 3 shows an implementation of the architectural model 
mentioned above, based on an RMI SIP surrogate: In this case, 
20 the Factory 114b and Parser 112b implementations are simply 
dummies . 

The Dummy ParserFactory 118b and the Dummy FactoryFactory 
120b respectively create the „Dummy Parser" runtime instance 
25 112b and the „Dummy Factory" runtime instance 114b. 

Though indicated as „dummy x \ still, said Parser 112b and said 
Factory 114b could check and/or enforce that the objects used 
in the object graph are typed as „java.io. Serializable". 

30 

Fig. 4 shows an implementation of the architectural model 
mentioned above, using a socket-based SIP surrogate: in this 
case, the Factory 114c and Parser 112c implementations are 
simply dummies. Nevertheless, one could also use the SDPng 
35 Parser 112a and SDPng Factory 114a to send .XML based strings 
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across the sockets using a proper Adapter 126c. The primi- 
tives are manually mapped into messages to be sent over sock- 
ets, thus implementing a proprietary Remote Procedure Call . 
(RPC) mechanism. . . 

The Dummy FactoryFactory 120c and Dummy ParserFactory 118c 
create respectively the „Dummy Parser" runtime instance 112c 
and the „Dummy Factory" runtime instance 114c. 

Though indicated. as „dummy x \ still, said Parser 112c and said 
Factory 114c could check and/or enforce that the objects used 
in the object graph are typed as „java.io.Serializable" . 

In the following subsections, the software components applied 
within the scope of the E2ENP UA 128 according to the under- 
lying invention shall briefly be described from the viewpoint 
of the component. For each software component, its require- 
ments, offered services and constraints are described and 
also its relations to other software components. This de- 
scription serves as the basis for the detailed design. 

Fig. 1 shows all software components and their usage rela- 
tions. A software component is assigned to a layer and may 
have relations to components on the same or a lower layer but 
not to software components on a higher layer. The layers do 
not have the strict meaning of encapsulating a lower layer. 

Accordingly, the entity using the services offered by a given 
API will, be referred to as Service User, whereas the entity 
implementing the services of said API will be referred to as 
Service Provider. 

The E2ENP UA API 101b (the aforementioned IF2) exposes the 
E2ENP UA functionality to Service Users like QoS-aware appli- 
cations 130 and/or QoS Brokers 130, according to the BRENTA 
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model as described in [BRENTA] . This component realizes the 
specification of a generic API by defining a set of inter- 
faces and complex data types exchanged through said API. 

5 Thereby, said E2ENP UA API 101b allows multiple instances of 
Service Users to simultaneously access the E2ENP UA 128 func- 
tionality. More specifically, the E2ENP UA 128 offers the 
following services as described in [ReqSpec] : 

10 1. pre-negotiation of a multiplicity of alternative capa- - 

bilities and/or QoS Contracts (at both application and 
network level) ; 

2 . management of leased pre-negotiated information; 

3. session establishment ..with negotiation of a multiplicity 
15 of alternative capabilities and/or QoS Contracts (at 

both application and network level), potentially refer- 
encing pre-negotiated information; 
4.. same as point 2, but with additional local, peer, and 
network resource reservation coordination; 

20 5. re-negotiation, similar to points 2 and 3; 

" ' 6: session release*, with potential reservation release co- 
ordination. 

In order to expose these services, the E2ENP UA API 101b 
25 shall expose, respectively, the following primitives: 

1 . pre-negotiation; 

2 . leaseRenewal", which can be used for refreshing* or termi- 
nating a lease; 

30 3. negotiation, parameterized to indicate whether resource 

reservation coordination is required. If resource reser- 
vation coordination is required, the E2ENP UA 128 allows 
the Service User at the Offerer side to book the mutu- 
ally exclusive access to the resource reservation phase 
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via the bookNegotiation and/or bookRenegotiation primi- 
tive; . . . 

4. re-negotiation: If resource reservation coordination has 
been specified as required in the original negotiation 
Phase, the E2ENP UA 128 allows the Service User at the 
Offerer side to book the mutually exclusive access to 
the resource reservation phase via the bookRenegotiation 
primitive; 

5. release. 

The E2ENP UA API 101b has been designed based on the follow- 
ing design principles: 

1. Primitives are classified into Request (Reg), Indication .. 
tlnd), Response (Rsp) , and Confirmation (Cfm) primitives, 
according to the ISO/OSI model. Request (Req) and Response. 
(Rsp) primitives are invoked by the client application 130 
or middleware 130 implementation (also known as Service : 
User) , in order to respectively initiate or respond to a = 
particular message exchange. (In some cases the message 
exchange may involve a set of different messages being ex- 
changed between peers, thanks to the abstraction offered • 
by the given E2ENP UA implementation, whereas in other 
cases the message exchange is limited to the given message 
and its acknowledgment.) Indication (Ind) and Confirmation 
(Cfm) primitives are invoked by the E2ENP UA 128 (also 
known as Service Provider) to the registered- client-side 
of the Service User 130, in order to respectively indicate 
the arrival of a particular message exchange or to confirm 
the conclusion of a given message exchange. (Again, in 
some cases the message exchange may involve a set of dif- 
ferent messages being exchanged between peers, thanks to 
the abstraction offered by the given Service Provider, 
whereas in other cases the message exchange is limited to 
the given message and its acknowledgment.) The client-side 



2 6921 EP and P 26922 EP 

32 



of the Service User 130 must implement these primitives. 
To a request primitive generated by the" peer initiating 
the given protocol message exchange, corresponds an Indi- 
cation (Ind) primitive at the target peer. To a Response 
(Rsp) primitive generated by the target peer, responding 
to the given protocol message exchange, corresponds a Con- 
firmation (Cfm) primitive at the initiating peer. 

. In order to distinguish different Service Users 130, the 
E2ENP UA 128 exposes at . interface 101b (IF2.) one. Service- 
Access Point (SAP) per registered Service User 130. 
Thereby, any given Service User 130 can use more than one 
SAP at said interface 101b (IF2) in a one-to-many rela- 
tionship. • 

3. Users can only be registered with one Service User 130 at 

. a time, which means that each user will be associated with 
at most one SAP at said interface 101b (IF2) . 

4. In order to simultaneously and independently use different 
- session layer" protocols 110 (e.g. various SIP implementa- 
tions and/or RMIs) , the E2ENP UA 128 exposes at interface 
101c (IF3) one SAP per registered session layer protocol. 

5. In order to properly associate Service Users 130 -with un- 
derlying session layer protocols, the E2ENP UA 128 exposes 
at interface 101a (IFl). proper configuration mechanisms, 
which allow associating SAPs at interface 101b (IF2) with 
SAPs at interface 101c (IF3) in a one-to-one relationship. 
In this way, user using a given type of application 130 
will automatically and transparently be using the associ- 
ated session layer protocol as configured. 

6. When configuring a SAP at interface 101c (IF3) , the bind- 
ing of the.E2ENP UA 128 to the session-layer protocol 110 
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is done automatically. With the given SIP UA 110 Generic 
API at interface 101c (IF3) the binding in the opposite 
direction is done when registering a user with the E2ENP 
UA 128, and this leads to a registration of the user to 
the configured session layer protocol 110. 

7. The bidirectional binding of the Service User 130 to the 
E2ENP UA 128 is done by means of the bindReq and bindCfm 
primitives, where one of the parameters is a special iden- 
tifier, and the SAP ID (spld) uniquely identifies one of 
the configured SAPs at interface 101b <IF2) . 

8. Any given user of any given Service User 130 registers 
himself/herself on the proper Upper SAP by means of the . 
registrationReq and registrationCfm primitives, where one 
of the parameters is the aforementioned spld, which 
uniquely identifies the SAP of choice at interface 101b 
(IF2). 

9. In order to select the proper Upper SAP when locally ini- 
tiating any E2ENP session, the following primitives now 
feature a new parameter „String user" indicating the lo- 
cally registered user, which uniquely identifies the SAP' 
at interface 101b (IF2) said user is registered to: 



— renewLeaseReq and 

- bookNegotiationReq 

. To select the proper Upper SAP when locally initiating 
any E2ENP session, the already existing „String form" pa- 
rameter of the following primitives indicates the. locally 
registered user, which uniquely identifies the SAP at in- 
terface 101b (IF2) said user is registered to: 
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- preNegotiationReq and 

- negotiationReq 

11. The instances of the application or middleware FSM 130 
and of the E2ENP UA FSM 106 are uniquely identified, re- 
spectively, by the serviceUserld and serviceProviderld. 

12. A simplified version of the „observer design pattern" as 
described in [Gam] (implemented in Java with a derivation 
of the Java Beans event model) offers the mechanism al- 
lowing the Service User 130 to register (via a primitive 
called „Bind Request") for Indication (Ind) and/or Con- 
firmation (Cfm) primitive callbacks. 

13. In order to allow supporting E2ENP signaling extensibil- 
ity/ most of the primitives allow passing a payload: To- 
day, some of these primitives are in fact not designed to 
carry payloads, but there is a chance that the E2ENP 
specification might be reviewed. Thereby, some additional 
E2ENP information piggybacking could be required. 

14. In order to allow different types of Service Users 130 
accessing the services of the E2ENP UA 110, the payloads 
are typed as the Java' root class, java . lang. Object : In 
this way, applications 130 or middleware may use either 
internal custom representations of the information to be 
exchanged via the E2ENP (e.g. an XML-based representa- 
tion), or resort to the default information structure de- 
scribed above. 

Thereby, said E2ENP UA API 101b depends on the respective ap- 
plication 130 and/or middleware 130 using the services of 
said E2ENP UA 128, the applied E2ENP UA FSM 106, concerning 
the implementation of the Request (Req) and Response (Rsp) 
primitives, and the applied Factory 114 and Parser 112: The 
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chosen implementation of these 
of representation used for the 
this API. 



components dictates the type 
information exchanged through 



The E2ENP UA API 101b has been designed with the aid of the 
object-oriented paradigm, and is thus hereby described using 
the Unified Modeling Language (UML) . The information to be 
exchanged via the E2ENP is described above. The component is 
composed of a basic package, the org: :mind: : e2enp as depicted 
in Fig. 5. 

To this basic package belong the following interfaces: 

- The Provider 504 represents the interface that an E2ENP UA. 
Service Provider implementation conforming to the herewith 
specification, shall support for implementing Request (Req) 
and Response (Rsp) primitives. Tab. 1 lists the primitives 
exposed by the Provider interface 504. 

- The E2ENPUserAgentListener 502 generalizes all the inter- 
faces that Service Users shall implement for- intercepting 
Indication and/or Confirmation (Cfm) primitives generated 
by the E2ENP UA 128. 

Tab. 2 lists the primitives exposed by the E2ENPUserAgent- 
Listener interface 502. 

The E2ENPUserAgentListener interface 502 is specialized in 
the OffererListener interface 506 and the AnswererListener 
interface 508. The former is specially designed for the ap- 
plication- or middleware-initiating E2ENP procedures; the 
latter is specially designed for applications 130 or middle- 
ware 130 responding to said E2ENP procedures. 
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Tab. 3 shows the primitives exposed by the Of fererListener 
interface 506, and Tab/ 4 lists the primitives exposed by the 
AnswererListener interface 508. 

5 The „to/from"-parameters passed o*n by the pre-negotiation and 
negotiation primitives are addresses identifying E2ENP users 
(respectively, the Offerer and the Answerer) . The E2ENP UA 
128 maps these addresses to the specific syntax used by the 
given session-layer protocol that is used for piggybacking 

10 - -E2ENP information:^* in" the -case -of -this writing; SIP. The ' 
E2ENP addresses shall therefore be independent of the spe- 
cific session-layer protocol, and possibly of the transport 
protocol used underneath by the E2ENP UA 128. To this extent, 
a hew syntax, which has specially been designed for the 

15 E2ENP, shall herewith be proposed. 

Fig. 6 presents a forinal description of such a Universal Re- 
source Identifier (URI) syntax by using the Augmented Backus- 
Naur Form (ABNF) I Thereby, said specification is similar to 

20 the SIP URI syntax specification described in [Rosl], but de- 
liberately does not indicate any transport protocol parame- 
ter, except for the IP address and/or port number. As an ex- 
ample of E2ENP URI, „e2enp://dave: vG$18 09@acme .com" repre- 
sents a user named „Dave" at the „acme" organization, using 

25 password „vG$1809 Vk . The „/ /" indication is a form of a sepa- 
rator for default user cases, when the user is not indicated 
in the address. The example „e2enp: // :xyz%45637@acme .com" 
shows a default user (which is not indicated) with a password 
„xyz%45637". 

30 

The full or partial usage of 'the E2ENP address components de- 
pends on the domain model (proxying) and the address resolu- 
tion mechanisms, which are mainly part of the respectively 
applied session layer protocol (e.g. SIP) . The E2ENP UA 128 
35 should use at least the user (default user) name and the do- 
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main name to identify the communicating partners, if the ses- 
sion layer protocol is already offering some proxying and/or 
redirection mechanisms to identify the network paths. 

5 In the following subsections, the procedures executed by the 
E2ENP UA API 101b shall be described by means of a set of UML 
Message Sequence Charts (MSCs) . 

Fig, 7 depicts the simple pre-negotiation scenario in terms 
10 of an exchange of primitives through the E2ENP API. With re-, 
spect to these primitives, specific transport protocol mes- 
sages are exchanged between the Of f ererServiceProvider 704 
and the AnswererServiceProvider 706, but they are not indi- 
cated in Fig. 7 for the sake of generality. 

15 

Fig. 8 depicts the MSC for a simple session establishment 
scenario, wherein QoS negotiation and resource reservation 
coordination processes are highlighted. In the presented sce- 
nario, for the sake of simplicity, the confirmation of re- 
20 source reservation completion from the Offerer side arrives 
before the same happens at the Answerer side.. Likewise, this 
simple scenario assumes for the sake of simplicity that the 
resource reservation process succeeds in reserving exactly 
the amount of resource, which has originally been requested. 



The re-negotiation procedure is similar to the negotiation • 
procedure, except that the names of the primitives have been 
changed as follows: 



25 



Old Name 



New name 



bookNegotiation<type> 



bookReNegotiation<type> 



negotiation<type> 



reNegotiation<type> 



negotiationStatus<type> 



reNegotiationStatus<type> 



30 
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The Cache 104 is a database for saving different object iden- 
tifiers. In order to decouple the Service User identification 
scheme from the one specified for the E2ENP [ReqSpecJ , an 
E2ENP Cache 104 is used for: 



♦ saving and retrieving E2ENP session identifiers specified 
in [ReqSpec], . 

♦ saving and retrieving the E2ENP session identifiers han- 
dled by E2ENP UA FSM 106 (ServiceProviderlds) , and 

♦ saving and retrieving E2ENP UA API Service Users' session 
identifiers (serviceUserlds) . 

The Cache 104 'should be searchable for different identifiers 
and following different criteria set by the E2ENP UA 128. The 
E2ENP UA 128 is responsible for the Cache management. 

The cached objects correspond to the identifier object cate- 
gory. The Cache 104 maintains two types of data: 

♦ Pre-cached data: The' E2ENP UA pre-caches information (in- 
dexed by serviceProviderld as primary key, and service- 
User Id and E2ENP session identifiers specified in [Req- 
Spec] as secondary keys) during the execution of a given 
E2ENP pre-negotiation or negotiation procedure. Once the 
given procedure has been successfully completed, the pre- 
cached data remains cached, so that E2ENP UA API 101b 
Service Users have reference to such data during a later 
E2ENP session as described in [ReqSpec] . 

♦ Cached data: This information can be used later, during a 
new E2ENP pre-negotiation or negotiation procedure, as a 
reference to data, which has already been (pre-) negotiated 
among the peers. For each of said E2EPN sessions, the 
Cache 104 stores the association between the given Serv- 
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iceUserld and the corresponding E2ENP session identifier 
described in [ReqSpec] . Each entry in this Cache 104 is 
leased between peers and. should be refreshed over time as 
described in [ReqSpec] . The Service Users 130 themselves; 
are responsible for managing their own leases and (prer) 
negotiated information. The Cache 104 simply stores. non- 
persistently the correlations among previous E2ENP ses- 
sions . 

The E2ENP Cache 104 is a database used for managing the nego- 
tiation object IDs. The E2ENP UA FSM 106 requests the Cache 
104 services. In an embodiment of this invention, the Cache 
104 is designed as a set of java.util .Hashtable objects ref- 
erencing each other. An alternative implementation based upon 
tupel-space technology is left for further study. 

In order to keep the E2ENP UA 128 implementation simple, the 
Cache API 103 between the Cache 104 and the E2ENP UA FSM 106 
represents a. synchronous interface. 

In the implemented version of the underlying invention, a 
two-stage Cache 104 is used: 

♦ Level One (LI) of said Cache 104 saves pre-cached informa- 
tion in form of the following tupel (serviceProviderld, 
serviceUserld, FromSIPAddress, ToSIPAddress, E2ENPSession- 
ID) , where the FromSIPAddress and ToSIPAddress allow de- 
tecting dual seizures; the primary key is the service- 
Providerld. 

♦ Level Two (L2) of said Cache 104 saves pre-cached informa- 
tion in form of the following tupel (serviceUserld, 
E2ENPSessionlD) , where the primary key is the service- 
Providerld. 
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The" two levels of the Cache 104 are implemented as two dis- 
tinct singleton objects as described in [Gam], which are ini- 
tiated and managed by the E2ENP UA 128. The Cache objects run 
5 within the instance of the E2ENP UA 128. Fig. 9 depicts a UML 
Class Diagram of the org: : mind: : e2enp: : Cache sub-package that 
contains the Cache implementation. 

The singletons LevelOneCache 902 and LevelTwoCache 904 re- 
10 spectively represent the Cache level LI and the. Cache level 
L2 and provide APIs for creating, searching, and releasing 
Cache entries (LevelOneEntry 906 and LevelTwoEntry 908, re- 
spectively) . 

15 The methods provided by the API of the first and second Cache 
level (LI and L2) are depicted in Tab. 5 and Tab. 6, respec- 
tively. 

In the following subsection, an XML-based serialized trans- 
20 port representation shall be defined by means of an XML 

schema definition. Rather than defining such a format from 
scratch, the transport representation is based upon and using 
the baseline SDPng format definition. Aside from providing 
compatibility, it is also possible to use and benefit from a 
25 third-party library and profile definitions designed for 
SDPng as described in [Kut2] . Examples include but are not 
limited to the Real-Time Protocol (RTP) as well as audio and 
video codec profiles. 

30 In order to illustrate how the Factory API lOle and the Par- 
ser API lOld share common transport representation syntax, 
the following subsection provides one possible definition for 
such a format. The XML description of E2ENP extends and uses 
the baseline SDPng XML description format. 
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The XML representation for E2ENP (in the following, E2ENP 
will be used synonymously for this representation) has chosen 
to be an extension to the SDPng baseline XML definition. The 
5 main reason for this decision is that SDPng is expected to be 
standardized by the IETF, which results in some major bene- 
fits: 

♦ E2ENP as an extension to SDPng will be able to benefit 

10 from external contributions to SDPng-like profile and li- 

brary definitions. There are already examples pointed out 
in the SDPng draft [Kut2], namely the audio and RTP pro- 
file. These extensions are already incorporated into the 
specification of the E2ENP XML. 

15 

♦ Applications 130 that implement the future SDPng standard 
can more easily be enhanced to also support E2ENP, ideally 
by simply linking the E2ENP module to the application 130. 
Likewise, in heterogeneous environments, applications 130 

20 which do not support E2ENP are still able to work. with the 

SDPng-specif ic parts and do not break interoperability 
completely. 

The E2ENP XML representation is formally specified by an XML 
25 Schema definition as defined by the W3C. The schema defini- 
tion can roughly be separated into three parts, one contain- 
ing type definitions such as enumerations for attribute val- 
ues or the definition of common content models as complex 
types. The main part defines the top-level E2ENP sections 
30 (i.e. elements), which are also plugged into SDPng using the 
substitution group mechanism. Finally, the third part defines 
E2ENP-specific elements with no relation to SDPng, which are 
used to completely define the content model of the top-level 
elements . 

35 
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As can be seen in Fig. 10, descType 1001 - originally defined 
in SDPng - is redefined in such a way that the E2ENP-specif ic 
header, section „purpose M ; 1002 appears as a legal child of the 
„desc root" element. E2ENP defines a „qosdef" section which 
can be used as a substitute for the „sdpng:d" element, the 
only valid child for the „sdpng:def" 1003 section, similarly, 
„qoscfg" may be used instead of „sdpng:c", in turn the only 
valid child for the „sdpng:cfg" 1004 section. The E2ENP- 
specific element types will be described in the following.. 

The extensions and plug-: ins to SDPng are illustrated in Fig. 
11, which shows how elements in substitution groups can be 
used to replace the head element of this group. 

Here, „sdpng:d" 1107 is the head element which may be substi- 
tuted by. any of the.: members of the substitution group,, that 
is, „audio : codec" 1108, „e2enp : qosdef " 1109, „rtp:pt" 1110, 
„rtp: transport" 1111 (which in turn again is the head element 
of a nested substitution group) and „video:. codec" 1113. Thus, 
by using the substitution group mechanism combined with the 
'XML namespaces concept, it is possible to define modular ex- 
tensions, to any XML schema • definition. Additionally, . the sub- 
stitution .group- member „rtp:udp" 1112 can further be enhanced 
in order to support the Option sub-group described in [Bos2], 
thereby incorporating an option similar to that suggested by 
[Bos2] (not shown in Fig. 11); 

The aforementioned „qoscfg" element 1400 is defined in the 
substitution group headed by „sdpng:c", which in turn is a 
valid child of the „sdpng:cfg" section. 

Using the „purpose" 1201. element depicted in Fig. 12, it is 
possible to convey additional information about the negotia- 
tion process in the external description. The general struc- 
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ture of how the purpose element is defined is shown in Fig. 

12. ........ 

Thereby, the header defines to which session the current mes- 
sage belongs to. It can also establish references to previous 
sessions by means of the „use" 1202 element, making it possi- 
ble to reference definitions from these sessions. 

Depending on what the E2ENP message is intended for, either 
the description" 1203 or the mediation" 1204 element should 
be present. For example, with the aid of the description" 
1203 element it is possible to state the kind of a message, 
i.e. Request (Req) or Response (Rsp) and what negotiation- 
mode should be used (push, pull, push-pull). 

Fig. 13 illustrates the general structure of the „qosdef" 
element 1300. However, there is. a constraint on the usage of 
the legal child elements, depending on the value of the 
„name" attribute of the qosdef element 1300. There are two 
possible values, capabilities" and contracts" . Depending on 
that, the „qosdef" section 1300 either specifies capabilities 
of a peer or, in the case of contracts, defines validated 
contracts that have been validated by entities using the 
E2ENP UA 128. 

- Specifying Capabilities: In case the „name" attribute's 
value of the „qosdef" element 1300 is capabilities", the 
valid child elements are „audio : codec" 1301, „ video : codec" 
1302, and „rtp:pt" 1303. The respective codec elements rep- 
resent system capabilities of the peer in terms of audio 
and video codecs and their .configuration. By using the 
„rtp:pt" 1303 element, it is possible to specify a desired 
RTP payload format for the given capabilities. 
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- Specifying Contracts: In this case, the attribute value of 
the- „name"- element of the qosdef element 1300 has to be 
„contracts" . Then, the valid child elements are „policy" 
1304, „audio" 1305, and „ video" 1306. The „policy" element 

5 has to appear exactly once. It specifies the usage for ne- 
gotiating the resource management policies to enforce. It 
is possible to use a policy to optimize one. or several as- 
pects of system behavior, such as optimization of memory 
usage, CPU load, network traffic or power consumption. In 

10 order to achieve more flexibility, these atomic aspects . can 
be combined by using predicates. The elements following the 
„policy M 1304 element can be one or many „audio >x 1305, 
„video x> 1306, „data" 1308, and „control xx 1307 elements. 
These elements describe the QoS Contracts for the respec- 

15 tive data streams. By using the >,rtp:map xx 1309 element it 
is possible to define a mapping between an application 
level QoS Contract and a specific RTP payload format. 

Fig. 14 illustrates the general structure of the „qoscfg M 
20 element 1400. This section allows defining adaptation paths 

(AP) as well" as QoS correlation and time synchronization con- 
straints at various levels of abstraction, starting from 
stream-level QoS Contracts. Each level of abstraction is 
identified by the attribute „name" of this section. Possible 
25 values include „stream x V „stream-group x V „session x V and 

^application^. Thus, the . definition of adaptation paths is. 
possible at different* levels, including stream-level adapta- 
tion pathsfas well as higher-level APs .' The „context xx 1401 
elements define possible associations of the given streams, 
30 thus allowing to define time-synchronization and/or QoS cor- 
relation constraints. As such, the „context xx 1401 elements 
basically describe high-level QoS Contracts. 

In the following subsection, a brief overview of the Parser 
35 API lOld shall be given. 
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The Parser API lOld provides primitives, which can be used to 
parse a description in some transport representation and. genr- 
erate an object representation according to IF2. In order, to 
be able to loosely couple the E2ENP UA 128 and the Parser. 
112, this object representation is abstracted in such a way 
that it is expressed as a j a va.lang. Object. As already 
pointed out, the only requirement for the transport represen- 
tation is that it implements the java.io.Serializable. inter- 
face. This can be interpreted in the sense that the transport 
representation is un-typed, thereby providing much flexibil- 
ity regarding what this representation can actually look 
like. 

The transport representation may contain references to exter- 
nal, previously defined entities. These references are left 
untouched and unresolved by the Parser 112. This issue is. 
handled later in the E2ENP UA 128 or higher layer entities. 

The Parser API lOld provides . one primitive for each message i 
type to be passed. Like this, the message types are repre- 
sented implicitly and do not need to be considered in the ob- 
ject model. For each message type, the Parser 112 offers one 
primitive to parse the offer and the answer of the respective 
message type. Therefore, the general pattern depicted in Fig.. 
15 for the Parser API lOld primitives is 

Object parseXXX(Serializable input). 

Thereby, „XXX" denotes a placeholder for the names of primi- 
tives like NegOffer or PreNegAnswer, etc. (see the API defi- 
nition below for more details) . 

In addition to these general parsing methods, the Parser API 
lOld provides some specialized primitives intended to navi- 
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gate through the content wrapped in the serialized represen- 
tation- These primitives can be used by clients to access 
specific information or data on an abstract level, independ- 
ent from the actual representation. Thus, if the representa- 
5 tion changes due to future protocol enhancements, the clients 
which use older versions of the representation are not af- 
fected by the new changes since the information access meth- 
ods do not change, 

10 _As the actual carrier protocol should be. exchangeable, there 
is a need for providing functionality to exchange the actual 
Parser 112 implementation as well- As described above, this 
mechanism has to be the same for the Parser 112 implementa- 
tion and for the carrier protocol . 

15 

Therefore, a ParserFactory API is defined which provides 
primitives to create an actual Parser 112 implementation in- 
stance (factory 118 depicted in Fig. 1 shows an implementa- 
tion. of. such a. Parser Factory).. Additionally, it is possible 
20 to register new actual Parser 112 implementations for any 

given carrier protocol. 1 

The communication between the E2ENP UA 110 and the Parser 112 
could be asynchronous, e.g. implemented by an active request 

25 interface and a passive confirmation interface. However, this 
option is not appropriate for the underlying design, because 
some gain in performance and . flexibility is opposed by much 
more complicated state models for the FSMs 106 of the E2ENP. 
One consequence of this decision is that the E2ENP UA 128 and 

30 the Parser 112 (and also the Factory 114) communicate syn- 
chronously and thus have to share a common address space, 
which in most circumstances is a reasonable assumption- 
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Another consequence of this decision is that the Parser 112 
(and also the Factory 114) have to be designed as thread- 
safe, re-entrant libraries. 

5 The object representation, generated during the parsing and 
passed as a result back to the calling E2ENP UA 128, is de- 
scribed very abstractly by just using the java. lang. Object 
class, in order to provide loose coupling of the Parser 112 
and the E2ENP UA 128. The actual classes implementing the 
10 Parser 112 for a given transport representation and a given 
object model, used in the E2ENP UA 128, have to be fitted to- 
gether by configuration. 

The actual Parser 112 and Factory 114 implementations have to 
15 agree on a common format for the transport representation. 
The definition of these formats is implementation-specific 
and corresponds to the actual Parser 112 and Factory 114 com- 
ponents, even though the usage of existing standards is en- 
couraged and envisioned. Therefore, a format has-been de- 
20 fined, which is compatible to the baseline SDPng definition. 

The registration functionality offered by the ParserFactory 
API can be handled in different ways. However, this is up to 
the actual ParserFactory 112 implementation. Some options 
25 what can be done with registration are: 

♦ Registrations may be stored permanently to survive multi-- 
pie application life cycles . 

♦ Registrations may be made public for the use of other ap- 
30 plications 130, which also implies permanent storage. 

♦ Registrations may only be stored in a transient way for the 
current application life cycle. 

Applications 130 may check if they have instantiated a match- 
35 ing pair of Parser 112 and Factory 114 by calling the respec- 
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tive getTypeO methods of these instances and comparing the 
returned values for equality. The usage of a non-matching 
pair of Parser 112 and Factory 114 by an application 130 may 
result in unpredictable results and undefined or even errone- 
ous behavior. 

In the following, the dependencies shall briefly be summa- 
rized. 

♦ IF2 Object Model: This is only an implicit dependency that 
actual implementations of the Parser 112 have to fulfill. 
In general, this dependency is removed by the fact that 
the Parser' 112 simply creates java.lang. Object instances. 
In a specifically configured system however, which will 
actually be created, instances of the specific object 
model classes are used in the E2ENP UA 128. 

♦ Transport Representation: Similar to the dependency above, 
an actual Parser 112 of course needs a well-defined struc- 
ture of what it has to create. Thus, it depends on the re- 
spective definition of the transport representation. But 
in general, by abstractly describing the transport repre- 
sentation using java.io.Serializable, this dependency is 
removed from the design. 

The primitives to be implemented by the Parser API lOld can 
be taken from Tab. 7. By contrast, the primitives to be im- 
plemented for generating a specific Parser 112 are listed in 
Tab . 8 . 



The ParserFactory API is realized by the class E2ENPContent- 
Handler Factory in the package org. mind. e2enp. content, also 
referred to as parser-factory implementation, it is designed 
as a singleton instance, so that all its clients can use reg- 
istrations made earlier. Currently, the singleton instance 
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created is a default implementation, but for future releases 
it is planned to provide a configurable approach (based on 
specific system properties) to determine the class to be used 
for the singleton instance. Methods provided by the E2ENP- : 
5 ContentHandlerFactory class are depicted in Tab. 11. > 

In the following subsection, the implementation of the Parser 
112 needed for an XML-based transport representation shall 
briefly be described. Thereby, a possible Parser 112 imple- 

10 mentation for the XML-based transport representation is pro- 
posed. Fig. 17 describes the general structure of a Document 
Object Model (DOM) tree, modeled as a class DocumentTree 
1702, which aggregates one DocumentNode 1704 and can be in- 
terpreted as the document root element. Each DocumentNode 

15 1704 in turn aggregates between 0 and N children, thus recur- 
sively describing the tree structure. 

The Parser 112 for this . representation can be implemented by 
using the „visitor design pattern" as described in [Gam] . The 

20 structural overview is given in Fig. 18. Thereby, a- generic 
Parser 112 visitor class pVisitor 1808 is defined to use, or 
to be precise visit, 1 to N DOMNodes 1806. In order to handle 
derived DOMNodes for each specially derived DOMNode subclass, 
a specialized visitor is defined. (Even if the „visitor pat- 

25 tern" is intended for handling only subclasses, this concept 
can easily be extended in such a way that different element . 
nodes are interpreted as categories of their own.) 

In the following, the Application Programming Interface (API) 
30 applied to the Factory 114 shall briefly be described. 

The Factory API lOle provides primitives which can be used to 
create a transport representation for a given object repre- 
sentation according to IF2. The loose coupling of the E2ENP 
35 UA 128 and the Factory 114 is realized via the abstraction of 
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the object representation (passing through the Factory inter- 
face lOle) as a java. lang. Object . As already pointed out/ the 
only requirement for the transport representation is. that it 
implements the java.io.Serializable interface. Therefore, the 
5 primitives defined by this API all return 
„ java.io.Serializable" objects. 

The object description may contain references to external, 
previously defined entities. These references are not handled 
10 or dereferenced by the Factory methods, . they are just used. 

Like the Parser 112, the Factory API lOle provides one primi- 
tive for each message type to be passed. Like this, the mes- 
sage types are represented implicitly and do not need to be 
15 considered in the object model- The general pattern for the 
Factory API primitives as depicted in Fig. 19 is: 

Serializable createXXX (Object input) 

20 Thereby, ;,XXX XX denotes a placeholder for the names of primi- 
- tives-l-ike NegOffer or PreNegAnswer, etc. (see the API . : defi- 
nition below for more details) . • 

Since the actual carrier protocol should be exchangeable,- 
25 there is a need to provide a functionality to make the actual 
Factory 114 implementation exchangeable as well. As described 
above, this mechanism has to be the same for the Factory 114 
implementation and for the carrier protocol. Therefore, a 
FactoryFactory API is defined which provides primitives to 
30 create an actual Factory 114 implementation instance. 

(factory 120 in Fig. 1 shows an implementation of such a Fac- 
toryFactory.) Additionally, it is possible to register new 
actual Factory 114 implementations for any given carrier pro- 
tocol in order to illustrate how the Factory API lOle and the 
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Parser API lOld share a. common transport representation syn- 
tax. ...... 

Communication between the E2ENP UA 128 and the Factory 114 . 
could be asynchronous, e.g. implemented by an active request 
interface and a passive confirmation interface. This option 
is not used in the scope of the underlying invention because 
some gain in performance and flexibility is opposed by much 
more complicated state models for the FSMs 106 of the E2ENP. 
One consequence of this decision is that the E2ENP UA 128 and 
the Factory 114 (also the Parser 112) communicate synchro- 
nously and thus have to share a common address, space, which 
in most circumstances is a reasonable assumption. 

Another consequence of this decision is that the, Factory 114 
(and also the Parser 112) have to be designed as thread-safe, 
re-entrant libraries. 

In order to provide loose coupling of the Factory 114 and the 
E2ENP UA 128, the transport representation, generated by the 
Factory 114 and passed back to the calling E2ENP UA 128 as a 
result, is abstractly described by using the 
java.io.Serializable class. Similarly, the j ava . lang . Ob j ect 
class abstractly describes the inputs of the Factory 114 
primitives. Thus, the actual classes implementing a Factory 
114 for a given transport representation and a given object 
model used in the E2ENP UA 128 have to be fitted together by 
configuration. 

The actual Parser 112 and Factory 114 implementations have to 
agree on a common format for the transport representation. 
The definition of these formats is implementation-specific 
and corresponds to the actual Parser 112 and Factory .114 com- 
ponents, even though the usage of existing standards is en- 
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couraged and envisioned. Therefore, a format is proposed 
which is compatible' to the baseline SDPng definition. 

The registration functionality offered by the FactoryFactory 
5 120 can be handled in different ways. Some options for regis- 
trations include but are not limited to: 

♦ Registrations may be stored permanently to survive multi- 
pie application life cycles. 

10 ♦ Registrations may be made ptiblic for the use of other ap- 
plications 130> which" also implies permanent, storage, 

♦ Registrations may only be stored in a transient way for the 
current application life cycle. 

15 Applications 130 may check if they have instantiated a match- 
ing pair of Parser 112 and Factory 114 by calling the respec- 
tive getTypeO methods of these instances and comparing the 
returned values for equality. The usage of a non-matching 
pair of Parser il2 and' Factory 114 by an application 130 may 

20 result in unpredictable results and undefined or even errone- 
ous behavior. 

In the following, the dependencies shall briefly be summa- 
rized: 

25 

♦ IF2 Object Model: This is only an implicit dependency that 
actual implementations of the Factory 114 have to fulfill. 
In general, this dependency is removed by the fact, that 
the Factory 114 simply expects java. lang. Object instances 

30 as input data. In a specifically configured system, how- 

ever, which actually will be passed in to the creation 
process, instances of the specific object model classes 
are used in the E2ENP UA 128. 
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♦ Transport Representation: Similar to the dependency above, 
an actual Factory 114 of course needs a well-defined, 
structure of what it has to create. Thus, it .depends on 
the respective definition of the transport representation. 
5 But in general, by abstractly describing the transport 

representation using java.io.Serializable, this dependency 
is removed from the design. 

The primitives specified by the Factory API lOle can be taken 
10 from Tab. 9. Additionally, the primitives to be implemented 
for generating a specific Factory 114 are listed in Tab. 10. 

The FactoryFactory API is realized by the class 
E2ENPContentHandlerFactory in the package org. mind. e2enp.con- 

15 tent, also referred to as factory-factory implementation. It 
is designed as a singleton instance, so that all its clients 
can use registrations made earlier. Currently, the singleton 
instance created is a default implementation, but for future 
releases it is planned to provide a configurable approach 

20 (e.g. based on specific system properties) to determine the 
class to be used for the singleton instance. Methods provided 
by the E2ENPContentHandler Factory class can be taken from 
Tab. 11. 

25 In the following subsection, a possible Factory 114 imple- 
mentation for the XML-based transport representation shall be 
presented. 

Like the Parser 112, the Factory 114 implementation uses the 
30 ^visitor design pattern" described in [GamJ . The structure is 
illustrated by Fig. 20. 

Again, a generic Factory 114 visitor class fVisitor 2002 is 
defined which visits 1 to N instances of Ob j ectGraphNode 2004 
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classes. For each concrete subclass of ObjectGraphNode, a 
corresponding concrete visitor class is* defined. 

In the following subsection, a brief overview of the SIP User 
5 Agent Generic API 101c (IF3) shall be given. 

Since the SIP User Agent Generic API 101c exposes the func- 
tionality of a generic SIP UA 110 to the E2ENP UA 128, the 
main object of this API is to mask the actual implementation 

10 of the SIP UA 110 from the E2ENP UA FSM 106. The SIP User; 

Agent Generic API 101c realizes the specification of such ge- 
neric API by defining a set of interfaces and complex data 
types exchanged through said API. Specific SIP UA 110 imple- 
mentations will be able to expose their native (eventually 

15 " standard) APIs by means of specific Adapters, which shall map 
the SIP API native interfaces into the SIP UA Generic API 
101c, and vice versa. 

The SIP UA Generic API 101c allows multiple users to simulta- 
20 neously access a given SIP UA 110 implementation (via multi- 
media applications 130 or middleware 130) for simultaneously 
establishing multiple SIP sessions. 

The SIP UA Generic API 101c also supports SIP Registrar im- 
25 plementations with the SIP signaling required by these enti- 
ties. To this extent, it should be noted that the SIP UA Ge- 
neric API 101c is not designed to allow the simultaneous sup- 
port of users' applications 130 and SIP Registrars on the 
same memory address space. With this design choice, SIP Reg- 
30 istrar implementations are thus forced to run as standalone 
server side entities, distinct from pure application 130 or 
middleware 130 entities (in the present context, the E2ENP UA 
FSM 106). Applications 130 and/or middleware 130 (in the pres- 
ent context, the E2ENP UA FSM 106), and SIP Registrar imple- 
35 mentations are examples of Service Users. A SIP UA 110 im- 
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plementation exposing the SIP UA Generic API 101c represents 
the Service Provider. 

The SIP UA Generic API 101c has originally been designed to 
5 expose an API from a specific open source SIP UA 110 imple- 
mentation, the Mitre's JSIP v. 0.8 library 

(http://jsip.sourceforge.net/), wherein API support is quite 
poor. The SIP UA Generic API 101c has been designed based on 
the following design principles: 

10 

1. The definition of a set of primitives identifying vari- 
ous SIP procedures abstracted at a relatively high- 
level, thereby simplifying the E2ENP UA FSM 106 design. 
Of course, the granularity of the procedures exposed by 

15 the current version of the SIP UA Generic API 101c re- 

flects to a certain extent the capability of the JSIP 
implementation. Other SIP UA 110 implementations .might 
offer more or less capabilities, which would require 
respectively more or less logic embedded in the corre- 

20 sponding aforementioned Adapters. . 

2. The current version of the SIP UA Generic API 101c fo- 
cuses only on the minimal set of features required for 
prototyping and testing the E2ENP UA 128. Therefore, 

25 the current version of SIP UA Generic API 101c is on 

purpose neither a complete SIP API specification nor 
meant to be standardized whatsoever. 

3. Primitives are classified into Request (Req), Indica- 
30 tion (Ind), Response (Rsp) , and Confirmation (Cfm) 

primitives according to the ISO/OSI model. Request 
(Req) and Response (Rsp) primitives are invoked by the 
client Service User of the IF3 101c, or by a SIP Regis- 
trar implementation in order to respectively initiate 
35 or respond to a particular message exchange. (In some 
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cases the message exchange may involve a set of differ 
. ent messages being, exchanged, between peers, ...thanks .to 
. the abstraction offered by the given SIP UA 110 imple 
mentation, whereas in other cases the message exchange 
is limited to the given message and its acknowledg- 
ment.) Indication (Ind) . and Confirmation (Cfm) primi- 
tives are invoked by the Service Provider 110 to the 
registered client-side of the Service User of the IF3 
101c in order to., respectively indicate the arrival of 
particular message or initiation of a particular mes- 
sage exchange or to. confirm the conclusion of a given 
message exchange. The client-side of the Service User 
of the IF3 101c has. to implement these primitives. To 
Request (Req) primitive generated by the peer initiat- 
ing the given protocol; message exchange corresponds an 
Indication (Ind) primitive at the target peer. To a Re 
sponse (Rsp) primitive generated by the target peer, 
responding to the given protocol message exchange, cor 
responds. a Confirmation (Cfm). primitive at the initiat- 
ing peer. 

4. A simplified version of the ^observer design pattern" 
as described in [Gam] (implemented in Java with a deri- 
vation of the Java. Beans event model) offers the mecha- 
nism allowing the Service- User to register (via a 
primitive called „Bind Request") for Indication (Ind) 
and/or Confirmation (Cfm) primitive callbacks'. 

. In order to allow supporting E2ENP piggybacking over 
SIP, each primitive allows passing a payload, e.g. SDP, 
SDPng, or Multipurpose Internet Mail Extension (MIME) 
content . 

. In order to allow dry-run tests of the E2ENP signaling 
logic without .the support of a real SIP UA 110 imple- 
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mentation and of SDP/SDPng Parsers 112 and/or Factories 
114, the primitives are. designed to. handle the payloads 
as generic objects (instead of plain objects represent- 
ing ASCII strings) that can be marshalled or demar- 
shalled when using Remote Procedure Call (RPC) mecha- 
nisms, like Java serialization or deserialization in 
combination with Java RMI . 

7. Since Mitre's JSIP Version 0.8 implementation used for 
designing this SIP UA Generic API 101c lacks proper 
support of the SIP Expires header field, which is typi-' 
cally manipulated by Service Users, an abstraction of 
this SIP header field has been created for handling any 
type of implementation of this field. This would be not 
necessary with other better SIP UA 110 implementa- 
tions, where the designer would have the choice to ei- 
ther change the SIP UA Generic API 101c (and therefore 
the E2ENP UA FSM 106 implementation) accordingly or 
provide an Adapter 12 6c mapping the Expires header 
field support of the given Service Provider (without 
changing the E2ENP UA FSM 106 implementation) . 

Further design choices are: 

• The E2ENP negotiation model described in [ReqSpec] is a 
key aspect of the E2ENP and a piece of information in- 
tended for being embedded into SDPng payload and ex- 
changed among peers on an end-to-end basis. For the sake 
of rapidly prototyping the E2ENP UA 128, a helper class 
named SipNegotiationModel 2216, representing the E2ENP 
negotiation model information, has provisionally been 
included into the SIP UA Generic API 101c. 

• Instead of uniquely identifying active sessions at ap- 
plication level by using the alphanumeric SIP Call Iden- 
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tifier header field, the SIP UA Generic API 101c uses a 
numerical integer Idehtif ier, named connectiorild. This 
choice was dictated by the following reasons: 

• Service users can more easily handle lists with 
numerical identifiers rather than with alphanu- 
merical ones. 

• Should the E2ENP UA 128 use other protocols in- 
stead of SIP in futuire, having generic primitives 
and generic session identifiers would help partly 1 
reusing the existing E2ENP UA FSM 106 design. 

The SIP UA110 associates an unused value of the con- 
nectionld to the SIP Call Identifier header field of an 
incoming INVITE, OPTIONS, MESSAGE, or REGISTER method. 
By applying the same design principle. Service Users re- 
questing the transmission of any of those methods would 
obtain the cbnnectionld value selected by the Service 
Provider in the Confirmation (Cfm) primitive associated 
with the original Request (Req) primitive. 

Unfortunately, this solution is affected by to two prob- 
lems : 

1. Without yet knowing the connectionld value associ- 
ated with a given Request (Req) primitive, Service 
Users can not correlate a Confirmation (Cfm) primi- 

- * - tive with its' corresponding Request (Req) primi- 
tive. 

2. Before the arrival of a Confirmation (Cfm) primi- 
tive, intermediate messages (eventually indicating 
failure situations) might generate additional 
primitives (e.g. a Connection Status Indication), 
which would lead to the same correlation problem 
described in the previous point. 
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To solve these problems, the Service User must be in 
charge of selecting an unused connectionld value and 
force the SIP UA 110 associating such value with a 
proper SIP Call Identifier header field value. 

The set of connectionld values allocated by the Service 
Provider in case of incoming INVITE, OPTIONS, MESSAGE, 
or REGISTER methods and by the Service User in case of . 
outgoing INVITE, OPTIONS, MESSAGE, or REGISTER methods ' 
should be distinct, so that the processing of incoming - 
and outgoing INVITE, OPTIONS, MESSAGE, or REGISTER meth- 
ods can simultaneously take place without interference. 

However, for the sake of simplicity, the SIP UA Generic 
API 101c has been designed with a centralized management 
of connectionld values allocation, embedded into the 
Service Provider itself. Service users are yet in charge 
of allocating connectionld values for outgoing INVITE, 
OPTIONS, MESSAGE, or REGISTER methods, but the actual 
allocation is delegated to the Service Provider by in- 
voking the getConnectionldO method exposed by Service 
Provider. This method can in no way be considered =a 
primitive itself, since it directly returns a value (the 
selected connectionld value) : For instance, this would • 
prevent implementing a loosely coupled interface, where 
primitives are exchanged between Service User and Serv- 
ice Provider via a (not RPC-like) message-based proto- 
col. In any case, Service Users and Service Providers 
can be designed without the centralized connectionld 
value allocation management, and yet being compliant 
with the SIP UA Generic API 101c, by simply not using 
respectively implementing the getConnectionldO method. 
As a special case, a connectionld can be reused in case 
of SIP re- INVITEs: in this case, a proper Boolean pa- . 
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rameter indicating whether this is a re-INVTTE, shall be 
passed to the connectionReq primitive (see below) . 

• Some primitives of the SIP UA Generic API 101c are SIP- 
specific: 

• provisionalAck (Reql IndlRsp I Cfm) , which is used to 
implement the PRACK method/ 

• register (Reql IndlRsp I Cfm) , which is used to imple- 
ment the REGISTER method, • 

• * options (Reql IndlRsp I Cfm) , which is used to imple- 

ment the OPTIONS method, and 

• message (Reql Indi | £sp I Cfm) , which is used to imple- 
ment the MESSAGE method. 

These primitives will eventually be mapped to more ge- 
neric ones in : a future E2ENP UA 128 design review in or- 
der to transform the 'S'lP UA Generic ARI 101c into a 
E2ENP 'Session Level Protocol API, which will be totally 
independent of the session-layer protocol actually used. 

• The current Version* of the SIP UA Generic API 101c de- 
sign is only partially compliant with the latest- working 
(as of this writing) version of the SIP specification 
described in" [Rosl] . For instance, REFER, DO, NOTIFY, 
SUBSCRIBE methods and many other features have been 
omitted since they are not essential for testing the 
E2ENP concept. The BYE and CANCEL methods are supported 
by the same Disconnection primitive. 
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Thereby, said E2ENP UA API 101b depends on the applied E2ENP 
UA FSM 106, concerning the implementation of the Indication 
(Ind) and Confirmation (Cfm) primitives and the Management 
5 component 102, which is used for configuring, . controlling, 
and resetting the underlying SIP UA 110. 

The SIP UA Generic API 101c has been designed using the ob- 
ject-oriented paradigm, and is thus hereby described. by using 

10 the Unified Modeling Language (UML) . It is composed of a ba- 
sic package, the so-called org: :mind: :sip: :sipApi as depicted 
in Fig. 21. To this basic package belong the classes SipEnd- 
User 2214 and SipExpiresHandling 2112. The SipEndUser .class. 
2214 represents a user accessing the SIP services offered by 

15 the SIP UA Generic API 101c. The SipExpiresHandling class 
generalizes the functionality for manipulating the SIP Ex- 
pires header field. The SipListener 2108 generalizes all the 
interfaces that Service Users shall implement for intercept- 
ing Indication (Ind) and/or Confirmation (Cfm) primitives 

20 generated by the SIP UA 110. The SipProvider 2110 generalizes 
all the interfaces that the Service Provider shall support 
for implementing Request (Req) and Response (Rsp) primitives. 

Four sub-packages complete the SIP UA Generic API 1 01c speci- 
25 fication: one, the org: : mind: : sip: : sipApi :: time, deals, with 
the SIP Expires header field abstraction, whereas the other 
three characterize different roles of the Service User: 

• org: : mind: : sip: :sipApi: :userAgent represents the applica- 
30 tion 130 / middleware 130 implementation (in the present 

context, the E2ENP UA FSM 106) ; 

• org: : mind: : sip: :sipApi: management represents the manage- 
ment entity 102; 

• org: :mind: : sip: :sipApi: registrar represents the SIP Regis- 
35 trar- implementation 2306. 
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The org,: : mind: : sip: :sipApi: :userAgent sub-package (cf. Fig. 
22) contains interfaces and classes specifying the part of 
the SIP UA Generic API 101c that the Service User of the IF3 
101c (in the present context, the E2ENP UA FSM 106) use for 
accessing the Service Provider . It consists of three major 
parts : 

1. Interfaces that Service Users of the IF3 101c shall im- 
plement for intercepting the Indication (Ind) and Con- 
firmation (Cfm) primitives generated by the Service 
Provider 110 : 

- SipUserAgentListener 2202: common to both client 
and server side; ; a specialization of the 

org: : mind: : sip: : sipApi :: SipListener interface 2108. 
. - SipUserAgentClientListener 2206: specific for the 
client side; a specialization of the SipUserAgent- 
Listener interface 2202. 

- SipUserAgentServerListener 2204: specific for the 

x -"server ' side; a specialization* of the SipUserAgent- 
Listener interface 2202. 



2. Classes bundling parameters for specific primitives 

(currently only the SipConnectionReq class 2208 for the 
Connection Request (Req) primitive, the SipRegistration 
Req class 2218 for the Registration Request (Req) primi 
~ tive, ''"and the sipRegiVtrationCfm class 2220 for the Reg 
istration Confirmation (Cfm) primitive) . Instances of 
these classes are passed as parameters of the given 
primitives to the modules implementing the primitives . 
This solution allows extending and/or changing API de- 
tails without disrupting the primitive signatures. 
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3. Interfaces and classes specifying the API that the 

Service Provider, shall support for being compatible with 
the SIP UA Generic API 101c. The SipUserAgentType inter- 
face 2210 specifies the set of Request (Req) and Re- 
sponse (Rsp) primitives that the underlying SIP UA 110 
implementation shall support for being compatible with 
the SIP UA Generic API 101c. The SipUserAgentType inter- 
face 2210 is a specialization of the 

org: :mind: :sip: : sipApi : :SipProvider 

interface. The SipUserAgent class 2214 wraps any given- 
implementation of the aforementioned SipUserAgentType 
interface 2210, by applying the ^abstract factory" and* 
„singleton" design patterns as described in [Gam] The 
^abstract factory" is defined by the SipUserAgentFactory 
interface 2212. The SipUserAgent class 2214 is designed 
to use a default implementation by using the deflmpl 
class attribute holding the fully qualified class name 
of the default implementation. Custom implementations of 
the aforementioned SipUserAgentType interface 2210 can 
be created by providing specific factory classes imple- 
menting the aforementioned SipUserAgentFactory interface 
2212. The SipUserAgent class 2214 provides a class 
method called setUserAgentFactory ( ) , which stores a sin- 
gleton instance of the given custom factory.' 

Finally, this sub-package contains a class named SipNegotia- 
tionModel 2216, which represents the E2ENP negotiation model. 
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The org: :mind: : sip: :sipApi: : registrar sub-package (cf. Fig. 
23) contains interfaces . and. classes specifying the part of 
the SIP UA Generic API 101c that SIP Registrar implementa- 
tions used for accessing the Service Provider. It consists of 
three major parts: 

1. Interfaces that Service. Users of the IF3 101c shall im- 
plement for intercepting the Indication (Ind) and Con- 
firmation (Cfm) ^primitives generated by the Service 
Provider: 

S.ipRegistrarListener 2302: common to both client 
and server side; a specialization of the 

org: :mind: :sip: :sipApi::SipListener 
interface 2108. 

2. Classes bundling, parameters for specific primitives 
(currently only the SipRegistrationlnd class 2308 for 
the Registration Indication (Ind) primitive, and the 
SipRegistrationRsp class 2310. for the Registration Re- 
sponse , (Rsp) primitive).. Instances of these classes are 
passed as parameters of the given primitives to the mod- 
ules implementing the primitives. This solution, allows 
extending and/or changing API details without disrupting 
the primitive signatures . 

3. Interfaces and classes specifying the API that the 
Service Provider 110 shall support for being compatible 
with the SIP UA Generic API 101c. The SipRegistrarType 
interface 2304 specifies the set of Request (Req) and 
Response (Rsp) primitives that the underlying SIP UA 110 
implementation shall support for being compatible with 
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the SIP UA Generic API 101c. The SipRegistrarType inter- 
face 2304 is a specialization of the 

org: :mind: :sip: :sipApi: :SipProvider 

interface 2110. The SipRegistrar class 2306 wraps any 
given implementation of the aforementioned SipRegistrar- 
Type interface 2304 by applying the ^abstract factory" 
and „singleton" design patterns as described in [Gam]. 
The ^abstract factory" is defined by the SipRegistrar- 
Factory interface 2312. The SipRegistrar class 2306 is 
designed to use a default implementation by using the 
deflmpl class attribute holding the fully qualified 
class name of the default implementation. Custom imple- 
mentations of the aforementioned SipRegistrarType inter- 
face 2304 can be created by providing specific factory 
classes implementing the aforementioned SipRegistrarFac- 
tory interface 2312. The SipRegistrar class 2306 pro- 
vides a class method called setRegistrar Factory () , which 
stores a singleton instance of the given custom factory. 

The org: : mind: : sip: : sipApi: : management sub-package (cf. Fig. 
24) contains interfaces and classes specifying the part of 
the SIP. UA Generic API 101c applied to the management entity 
102 for configuring and controlling the Service Provider. It 
consists of three major parts: 

1. Interfaces that Service Users shall implement for inter- 
cepting the Indication (Ind) and Confirmation (Cfm) 
primitives generated by the Service Provider: 

SipManagementLis'tener . 



2. Classes bundling parameters for specific primitives 
(currently only the SipConf igurationReq class 2406 for 
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the Configuration Request (Req) primitive) . Instances of 
• these classes are passed as" parameters of the -given 
primitives to the modules implementing the primitives. 
This solution allows extending and/or changing API de- 
tails without disrupting the primitive signatures. 

3. An interface specifying the API that the Service Pro- 
vider shall support for being compatible with the SIP UA 
Generic API 101c. The SipManager interface 2404 speci- 
fies the set of Request (Req) and Response (Rsp) primi r 
tives that the underlying SIP UA implementation shall 
support for being compatible with the SIP UA Generic API 
101c. 

The org: :mind: : sip: :sipApi: : time sub-package (cf. Fig. 25) 
contains interfaces and classes specifying the part of the 
SIP UA Generic API 101c that allow Service Users manipulating 
the SIP Expires header field. It consists of two major parts: 

i. Interfaces and classes specifying the API that the 
- -- Service -Provider shall ^support for being compatible 
with the SIP UA Generic API 101c. The SipExpiresType 
interface 2502 specifies the set of SIP Expires header 
field manipulation operations that the underlying SIP 
UA 110 implementation shall support for being compati- 
ble with the SIP UA Generic API 101c. The SipExpires 
class 250 6 wraps any given implementation of the afore- 
mentioned SipExpiresType 'inter fade" 2502 by applying the 
„abstract factory- and „singleton" design patterns as 
described in [Gam] . The ^abstract factory* is defined ■ 
by the SipExpiresFactory interface 2508. The SipExpires 
class 2506 is designed to use a default implementation 
by using the deflmpl class attribute holding the fully 
qualified class name of the default implementation. 
Custom implementations of the aforementioned SipEx- 
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. piresType interface 2502 can be created by providing 
specific factory classes implementing- the aforemen- 
tioned SipExpiresFactory interface 2508. The SipExpires 
class 2506 provides a class method called setSipEx- 
5 piresFactoryO , which stores a singleton instance of 

the given custom factory. 

2. The SipParseException class 2504 represents the excep- . 
tion thrown by the Service Provider whenever the pars- • 
10 ing of the SIP Expires header field fails, due to mal- 

formed syntax. 

In the following subsection, the procedures enabled by the 
SIP UA Generic API 101c shall be described by using a set of 
15 UML Message Sequence Charts (MSCs) . 

Fig. 26 shows how the Service Provider 110 is conf igured, • and 
how a Service User of the IF3 101c creates and binds as Serv- 
ice User its client and server sub-units with the Service 
20 Provider 110. Fig. 27 shows how a SIP session can be estab- 
lished through the SIP UA Generic API 101c according to the 
procedures described in [Rosl] . 

This procedure starts with a connectionReq primitive. invoked- 
25 by a peer acting as calling party (or initiator)., triggers a 
message exchange, which terminates only when the. peer acting 
as called party (or responder) after having initially re- 
ceived a connectionlnd primitive notifying the initiator's 
invitation to establish a SIP session, eventually accepts 
30 such invitation (after a number of negotiation and signaling 
steps), and replies with a connectionRsp primitive. 

The responder generates SIP-provisional responses through the 
connections tatusReq primitive invocations, which map at ini- 
35 tiator's side to connectionStatusInd primitive invocations. 
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The initiator acknowledges provisional responses with the 
PRACK method, by using the ProvisionalAckReq/Cfm primitive, 
which corresponds at responded s side to ProvisionalAck- 
Ind/Rsp primitive, respectively. 

5 

This procedure ends with the initiator receiving a connec- 
tionCfm primitive and the responder receiving a connection- 
Statuslnd primitive. The latter is due to the SIP three-way 
acknowledgment scheme described in [Rosl] . 

10 

Two procedures in this MSC are assumed to be executed auto- 
matically by the Service Provider: The generation of the ,,100 
Trying* provisional response at responder' s side,, and the 
generation of the final ACK signal at initiator's side. The 
15 latter can, however, be forced by the Service User itself via 
the connectionStatusRsp primitive, but this means that the 
Service User must accordingly be configured not to generate 
the ACK signal automatically. 

20 Final SIP responses indicating other reasons than success are 
generated either, automatically by the Service .Provider or ex- 
plicitly, by the responder' s Service User via the connection- 
StatusReq primitive. These SIP responses are notified to the 
initiator' s Service User via the connectionStatusInd primi- 

25 tive. 

Fig. 28 shows how the OPTIONS method is handled via the op- 
tionsReq|Tnd|Rsp|Cfm primitives. Fig. 29 shows how a SIP ses- 
sion can be released via the disconnectionReql Ind|Rsp|Cfm 
30 primitives. The MSC shows the case of BYE, but the same pro- 
cedure invoked during a connection establishment generates a 
CANCEL . 



In the following subsection, the Finite State Machine 106 
35 (FSM) applied to the E2ENP UA 128 shall briefly be described. 
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The core of the E2ENP UA 128 is composed of a Finite State 
Machine 106 (FSM) , which coordinates the overall functional- 
ity and implements a part of the aforementioned interfaces, 
5 More specifically, the FSM 106 implements the Service User 
part of the IF3, IF4 and IF5, and the Service Provider part 
of the IF1 and IF2. Furthermore, the E2ENP :UA FSM*106 makes 
use of the Cache 104 described above. 

10 The FSM 106 is designed hierarchically as a StateChart. In 
the Root State (cf. Fig. 30), the FSM 106 handles session- 
terminating events, either associated with/local or remote 
users' decisions. Furthermore, the Root State handles pre- 
negotiation, lease renewal, negotiation as Offerer/Answerer, 

15 re-negotiation, and session release processes. It should be 
noted that the term „negotiation M process is used for indi- 
cating a multimedia session establishment, -intertwined with , 
resource reservation coordination and QoS negotiation, as de- 
scribed in [ReqSpec] . 

20 

The role of the Offerer is taken by the peer who. is initiat- 
ing a session establishment with QoS negotiation and resource 
reservation, but also by the peer who decides to initiate a • 
re-negotiation. The role of the Answerer is always taken by 

25 the peer who is responding to an invitation to carry out a 
session establishment process with QoS negotiation and re- 
source reservation, but also by the peer who decides to re- 
spond to an invitation to carry out a re-negotiation. This 
means that a peer initially acting the Offerer role can later 

30 take either the Offerer or the Answerer role during a re- 
negotiation. And vice versa, a peer initially acting the An- 
swerer role can later take either the Offerer or the Answerer, 
role during a re-negotiation. 
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For the sake of simplicity, Fig. 30 does not detail the han- 
dling of primitives associated with I Fl ..(Management API) ; 
neither the internal interfaces with the FSM factory 106 nor 
the Cache 104 are taken into account. 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 30. 

Lower-level details of the negotiation process as Offerer/ 
Answerer are encapsulated in nested FSMs 106, respectively 
the NegOfferer sub-state '(cf. . Fig. 31) and the NegAnswerer 
sub-state (cf .. Fig. 32) . 

The NegOfferer sub-state contains a nested FSM 106 capturing 
the logic handling the negotiation process, as seen from the 
Offerer perspective. The NegAnswerer sub-state contains a 
nested FSM 106 capturing the logic handling the negotiation 
process, as seen from the Answerer perspective. 

In order to guarantee consistency and avoid deadlocks during 
the combined reservation of locals peer, and network. re- 
sources as described in [ReqSpec] , the FSMs 106 nested in the 
NegOfferer sub-state and in the NegAnswerer sub-state use the 
system-wide „_ResvMtx" FSM .106 for accessing the reservation 
phase on a mutually exclusive basis, with respect to other 
instances of the E2ENP UA FSM 106. The „_ResvMtx" FSM 106 in- 
teracts with various instances of the E2ENP UA FSMs 106 via 
atomic local methods invocation (e.g. via any specific system 
call provided by the . underlying Operating System) . 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 31. 

Lower-level details of the re-negotiation process as Offerer/ 
Answerer are encapsulated in nested FSMs 106, respectively 
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the ReNegOfferer- sub-state (cf. Fig. 33) and the ReNegAn- 
swerer sub-state (cf- Fig. 34). 

- The ReNegOfferer sub-state contains a nested FSM 106 cap- 
turing the logic handling the re-negotiation process, as 
seen from the Offerer perspective. 

- The ReNegAnswerer sub-state contains a nested FSM 106 cap- 
turing the logic handling the re-negotiation process, as 
seen from the Answerer perspective. 

In order to guarantee consistency and avoid deadlocks during 
the combined reservation of local, peer, and network re- 
sources as described in [ReqSpec] , the FSMs.106 nested in the 
ReNegOfferer sub-state and in the ReNegAnswerer sub-state use 
the system-wide „_ResvMtx" FSM 106 for accessing the reserva- 
tion phase on a mutually exclusive basis, with respect to 
other instances of the E2ENP UA FSM 106. The „_ResvMtx" FSM = 
106 interacts with various instances of the- E2ENP UA FSMs 106 
via atomic local methods invocation (e.g. via any specific 
system call provided by the underlying Operating System) . 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 33. 

This mechanism enforces a transaction-like processing of the 
resource reservation phase by enforcing various concurrent 
instances of the E2ENP UA Service Users to mutually exclu- 
sively access such a phase, as described in [ReqSpec] . In 
other words, the resource reservation mutex allows defining 
the phase between local admission control and final network 
resource reservation as a critical section. Combined with the 
contention resolution policy, this mechanism also guarantees 
that no deadlock situation as described in [ReqSpec] might 
affect the E2ENP whatsoever. 
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Concurrent- E2ENP UA Service User instances try to seize the 
mutex via suspensive method calls. The Service User instance 
owning the mutex releases it via the signal call event. 

5 

The „_ResvMtx" is associated with a priority, queue for allow- 
ing multiple requests to seize the mutex in a coordinated 
manner, based on their priority (cf. Fig. 35). 

10 Any request is served immediately if the mutex is unlocked; 
otherwise, the request is queued. Requests with high priority 
are queued in front of requests with low priority. Requests 
with the same priority are queued in a „First-In-First-Out" 
(FIFO), order-. 

15- 

All requests to acquire the mutex are limited in time. Upon 
expiration of such a (configurable) time, the given E2ENP UA 
Service User instance pending on the mutex is resumed with a 
return value indicating failure. 

20 

. . This- design, choice -allows detecting .(.and thus, preventing) 

starvation of concurrent E2ENP UA Service User instances sus- 
pended on the mutex, which occurs when the Service User in- 
stance owning the mutex is misbehaving (or maybe blocked) . 

25 This is of most importance, especially in case the ill- 
behaved Service User instance are suspended on some other ap- 
plication-specific mutex, semaphore or lock, eventually 
seized by one of the Service User Instances queued on the 
„_ResvMtx w : In such an unfortunate situation, a dead lock 

30 would in fact inevitably occur. 

When the timer associated with each blocked request expires, 
the priority of that request (specified in the parameter list 
of respectively the bookNegotiationReq or bookRenegotiation- 
35 Req primitives, cf . Tab. 1) should be higher than the prior-. 
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ity of the one for which the mutex was granted, the mutex 
would throw a signal event, congestionlnd, to the instance of 
the FSM 106 UA associated with the Service User instance own- 
ing the mutex. This event is caught by the E2ENP UA FSM 106 
Root state and mapped to a failurelnd primitive sent to the 
Service User instance owning the mutex. 

According to application-specific policies, such Service User 
instance might react on such event by rolling-back the cur- 
rent status of its activities and starting a release opera- 
tion, which in turn would force the release of the mutex, as 
indicated in Fig. 30. Should however such Service User in- 
stance act differently (either based on application-specific ' 
policies or because being blocked or just misbehaving), the 
other instances would nevertheless be able to detect the pro- 
longed delay on acquiring the mutex (after a configured num- 
ber of failed attempts to invoke the get method success- 
fully) , thanks to the bookNegotiationCfm (or bookRenegotia- • 
tionCfm in the re-negotiation case) primitives indicating a 
failure case (see Figs. 31 and 33, respectively)., m such 
cases, the notified E2ENP UA Service User instances might in- 
voke the mediation of an application-specific arbitration 
unxt. To manage all these exceptional cases/dead locks, the 
resetReq primitive can be issued at any time to cancel the 
current given session and release the mutex, if necessary. 

A key issue typically encountered when using mutex entities , 
xs the so-called priority inversion problem, which occurs 
whenever a task Tj owning the mutex has a lower priority than 
other tasks T k blocked on the mutex, and more precisely when 
the T 3 gets pre-empted by a task Tl with a priority greater 
than Tj but less than T k . 

Given the design choice of enforcing loosely coupled inter- 
faces to both the E2ENP UA Service Users and to the SIP UA 
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110, the E2ENP UA 128 containing the „_ResvMtx" implementa- 
tion cannot directly enforce well-known protocols, e.g. the 
Priority Inheritance Protocol or the Priority Ceiling Proto- 
col. This is after all a consequence of designing the E2ENP 
UA 128 as a software component. 

However, if the E2ENP UA FSM 106 is designed to handle a 
thread-pool for processing concurrently multiple instances of 
the FSM 106, the priority inversion problem might be tackled 
at least on this level. In this connection, the enforcement 
of the Priority Inheritance Protocol allows to achieve a good 
performance in handling the aforementioned problem. To this 
extent, the priority specified in the parameter list of the 
bookNegotiationReq primitive (or boo.kRenegotiationReq in the 
re-negotiatioh case, of. Tab. 1) issued by each E2ENP UA 
Service User instance is assigned as priority of the thread 
serving that FSM 106 instance. The „_ResvMtx" shall therefore 
temporarily raise the priority of the thread associated with 
the FSM 106 instance owning the mutex to the priority of any 
blocked thread if the priority of the latter is greater than 
the. one of the. former. .... . 

The E2ENP UA 128. thus provides the tools for solving deadlock 
and priority inversion problems: However, this is up to the 
applications 130 or QoS Brokers 130 using such tools to guar- 
antee that those problems will never occur. 

In the following .subsection, the ..resource reservation coordi- 
nation process shall be described. 

The NegAnswerer (cf. Fig. 32) and ReNegAnswerer (cf. Fig. 34) 
sub- states each contain an instance of the same composite 
state, the WaitForCoordDone sub-state (cf. Fig. 36), whose 
nested FSM 106 captures the logic handling the coordination 
of resource reservation signaling required before the An- . 
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swerer is actually alerted and the Offerer informed corre- : 
spondingly thereupon. 

The resource reservation coordination process is based on the 
mechanisms described in [Caml], with the following differ- 
ences: 

1. The preconditions described in [Caml] can be mapped to 
the E2ENP „qosdef « section and its corresponding nego- 
tiation process described in [ReqSpec] . 

2. The E2ENP prescribes the synchronization of the reserva- 
tion processes between peers (the „confirm" tag in 
[Caml]) as always mandatory due to the ^Economy Princi^. 
pie": This means- that the end-to-end signaling of the . 
„confirm" tag (or anything equivalent) is unnecessary 
and thus shall not be supported by any E2ENP implementa- 
tion. 

3. In case of no network resource reservation carried out 
by the Offerer, the Answerer shall determine this case 
by examining the preconditions sent by the Offerer,, and 
correspondingly mark the state RemoteTokenAchieved as ... 
active in Fig. 36, so that the Answerer will be able to 
transparently deal with resource reservation coordina- , 
tion. 

Impact on SIP implementation (e.g. the introduction of the 
status response and the new value preconditions" for the 
^Supported" header field of the OPTIONS method) are left for 
further study. 

An important aspect is that the E2ENP described in [ReqSpec] 
explicitly claims that the Economy Principle is always re- 
quired, including the concept described in [Caml] of allowing 
both end-to-end and segmented reservations. In the latter 
case, enforcing the Economy Principle might not always be de- 
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sirable. There might in fact be situations where reservation 
can be well done "locally on beforehand with ho cost and/or 
major impact on session establishment. For instance, some us- 
ers might be attached to an intranet or wireless LAN, where 
5 network resource reservation might be free and starving other 
users might flexibly be handled. Therefore, the original 
E2ENP shall accommodate this case and rely on the applicabil- 
ity of the Economy Principle to allow the aforementioned 
case. 

10 

It should be noted that the E2ENP does not imply that a di- 
rect interface to reservation entities is available: It is up 
to the applications 130 or QoS Broker 130 to access those en- 
tities. If the latter wishes to execute a „pre-reservation" 

15 of network resources, it might do that, but the E2ENP signal- 
ing would still give the right timing to the applications 130 
or QoS Broker 130, thereby informing it when. the reservations 
at all sides have been accomplished according .to the Economy 
' Principle, e.g. which signal has reached the level of the de- 

20 sired QoS (even though best effort communications might well 
have been started err beforehand, if specified by the applica- 
tions 130 or QoS Broker 130, respectively) . 

For the sake of simplicity, the model depicted in Figs. 30 to 
25 36 only partially details the handling of unexpected events 
and error cases. Tab. 18 completes the description of said 
model by indicating thie behavior expected in case any of such 
events ' or* errors ' occur . 

30 A set of timers is defined to avoid that the E2ENP UA FSM 106 
gets stuck in a state waiting for an event from the Service 
User and/or the SIP UA 110. The treatment of timers for han- 
dling primitives across the E2ENP UA API 101b (T1-T22) does 
not prescribe the E2ENP UA FSM 106 taking autonomously cor- 

35 rective actions, except for a few cases (missing negotiation- 
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Req in Root .NegOff erer .WaitNegReq and renegotiationReq in 
Root. ReNegOff erer. WaitReNegReq) . The E2ENP UA FSM 106 simply 
notifies the misbehaving Service User about the detected 
problem via the failurelnd primitive upon which the Service- 
User is supposed to clean up and send a releaseReq primitive 
to the E2ENP UA FSM 106. However, if this counteraction does 
not succeed, e.g. owing to massive problems at the Service 
User side, the E2ENP UA FSM 106 would detect this situation 
upon expiration of yet another timer: in this case, the E2ENP 
UA FSM 106 finally takes the decision to release. the SIP con- 
nection and the overall E2ENP session. To manage all these 
exceptional cases/dead locks, the resetReq primitive can be 
issued at any time to cancel the current given session and . 
release the mutex, if necessary. 

However, the composite states Root . ReNegOff erer, Root.Neg- . 
Answerer, Root .ReNegOff erer, Root .ReNegAnswerer may detect a 
later arrival of the missed primitive (eventually triggered 
by the invocation of the failurelnd primitive) by using each 
an History state (cf. Figs. 31, 32, 33, and 34). .With this 
solution, the late primitive arrival would be caught in the 
right original state and processed correctly. This means that 
whenever the aforementioned timers expire, the- aforementioned 
composite states shall each take care of updating the history 
to point to the state where the timer expired. 

Should a SIP primitive fail, specific timers (T101-T106) 
would detect the failure at the Root .ReNegOff erer, Root.Neg- 
Answerer, Root .ReNegOff erer, Root .ReNegAnswerer composite 
states: In these cases, the same procedure as described above 
(based on the failurelnd primitive) shall be enforced. ■ 



For the interface, similar approaches to the potential prob- 
lem of primitive failure have to be pursued by means of the 
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management, entity 102, which is however not detailed in this 
section. 

For properly implementing the E2ENP concept, the dual seizure 
5 event (peers simultaneously initiating a negotiation session 
with each other) shall be properly detected and handled in 
order to allow that consistency is guaranteed and that any 
correlation between outgoing and incoming invitations is en- 
forced. 

10 

The former issue can.be addressed by using a mutex for regu- 
lating the access to the Economy Principle phase on a system- 
wide basis (the , „_ResvMtx" described in the sections above). 
For enforcing any correlation, some additional support is re- 
15 quired instead.. Two possible approaches are envisioned: 

a. to use the push-pull model for allowing both Offerer and 
Answerer having a chance to send an offer to the peer, 
thus avoiding the. possibility of simultaneously generating 

20 two negotiations in both directions for the same session; 

b. , to treat , the attempt of handling negotiations simultane- 

ously in both direction as a double seizure, which re- 
quires a contention resolution policy to be enforced (e.g. 

25 wait on a random timer. on both sides, and then retry) . 

But this would mean that both peers should use the same 
external representation . of the session ID in order to be 
able to detect a double seizure. Otherwise, each of the 
two UAs would treat the outgoing and incoming negotiations 

30 as independent sessions. This would be similar to the case 

peer A invited peer B to e.g. a videoconf erence, while 
peer B would invite peer A to another videoconf erence, 
whereas the videoconf erence could actually be the same. 
The way E2ENP defines the external representation of the 

35 session ID described in [ReqSpec] allows the two peers 
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creating only distinct IDs . Therefore, the E2ENP-speci- 
fication per se does not allow detecting double, seizures 
at all. 

A reasonable solution to this issue is to enforce the push- 
pull model (first approach) as much as possible and to in- 
clude in the re-negotiation phase the possibility to allow 
the Answerer to send an offer to the Offerer at a. later time 
(i.e. after the first negotiation has been entirely com- 
pleted) . 

This means that the E2ENP shall allow the Of ferer . and/or any. 
Answerer to negotiate with the other Answerers and/or the Of- 
ferer upgraded or new information for establishing QoS^aware 
multimedia sessions. This means that re-negotiations can be . 
subdivided in two classes: 

• planned re-negotiations as described originally in 
[ReqSpec] , 

• unplanned re-negotiations, which are used for negotiat- 
ing upgraded or new information during the lifetime of a 
session. 

An explicit Boolean parameter in the pre-negotiation primi- 
tive indicates which of the two classes the given primitive 
should be used for. Of course, the semantics could be in- 
ferred from the information passed, which would be different, 
in the two cases, but the Boolean parameter is a good trade- 
off between having this distinction, which has explicitly 
been made for improving performance, and the need to keep the 
E2ENP UA API 101b and FSM 106 simple by avoiding additional 
primitives . 

However, applying the aforementioned solution might not suf- 
fice in the general case since a non-E2ENP compliant SIP UA 
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110 might interfere with E2ENP compliant peers, or one of the 
participants might try to invite some of the other partici- 
pants to a parallel multimedia session and use the E2ENP to 
accomplish this. 

5 

SIP loosely tackles the dual seizure problem by suggesting a 
contention resolution policy (indicated as a „MAY M require- 
ment in [Rosl].) , whereby peers abort the invitation by reply- 
ing with an Internal Server Error response/ carrying a Retry- 
10 After SIP header field set to the time after which the remote 
peer should retry. , 

The dual seizure detection is accomplished by matching all 
messages between each given couple of users, via the To-, and 
15 From-SIP header fields . This means if a first user is using 
UA A and sends an INVITE to a second user on UA B, and vice 
versa, both users can detect the dual seizure by using the 
couple (To, From) as a unique identifier for correlating the 
two INVITES. 

20 

But this is not exactly the ..way E2ENP identifies sessions. If 
users are engaged in two independent yideoconf erences, the 
E2ENP can actually distinguish such cases by using the ses- 
sion ID described in [ReqSpec] . In any case, the biggest is- 
25 sue is what would the SIP UA 110 do in such a case, given 

that the aforementioned SIP requirement is a MAY requirement 
and thus not necessarily supported by all SIP implementa- 
. tions 

30 One has to assume that the aforementioned policy may be im- 
plemented: Thereby, the E2ENP UA 128 would not notice the 
dual seizure, except for an indication of an unsuccessful ne- 
gotiation or re-negotiation phase. But one could also get 
into dual seizure troubles if the contention resolution pol- 
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icy is not supported by the underlying SIP UA 110 implementa- 
tion. 

To tackle the latter case, the Cache 104 should store for 
each of its entries also the (E2ENPFromAddress, E2ENPTO- 
Address) couple associated with the outgoing INVITE and use 
this information for correlating an incoming . INVITE with a 
pending outgoing INVITE registered in the Cache 104, thus de- 
tecting the double seizure case: This would then trigger a 
contention resolution policy. This means that every incoming 
INVITE received after sending an INVITE should be checked by 
searching the Cache 104 with the aid of a secondary key, us- 
ing the (From, To) couple. Although this is an extra effort, 
it is only limited to the specific case of receiving an IN- 
VITE after having sent one. 

As an alternative to the contention resolution policy sug- 
gested by [Rosl], which is eventually implemented by the un- 
derlying SIP UA 110, the E2ENP UA 128 shall support a more 
general policy, which is also applicable to complex scenarios 
like one-to-many or many-to-many described in [ReqSpec] . 

Whenever initiating a negotiation or pre-negotiation phase, 
the E2ENP UA 128 should not only include the- session ID de- 
scribed in [ReqSpec] in the offer sent within the INVITE but 
also a hash thereof which takes the IP address of the comput- 
ing unit where the E2ENP UA 128 is active into account and a 
time stamp. This hash might also be signed digitally in order 
to improve security aspects [ReqSpec] . The hash will be used 
as a substitute for the session ID in any subsequent SIP mes- 
sage. Should a dual seizure occur, the E2ENP would detect it 
by using the aforementioned (From, To) couple. Thereby, said 
contention resolution policy would be applied as follows: 
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♦ If the two peers are not already involved in multimedia 
sessions (which means no entry in the Cache 104 for a 
given local peer), each peer would compare the hash it 
generated with the one received from the peer. The peer 
5 with the biggest value is automatically chosen as Offerer 
and thus proceeds with the pre-negotiation or negotiation 
phase as such, whereas the other peer, the „loser M , auto- 
matically moves to the Answerer mode, according to the 
following MSC: 

10 

Application (130) E2ENP UA (128) 

• negotiationReq > 

< abortlnd 

< negotiationlnd 

negotiationRsp > 



♦ If the two peers aire already involved in multimedia ses- 
sions (which means an entry in the Cache 104 for the given 

20 (From, to) couple) , the „bully" process described in the 

■' previous pbxrit could be applied as' well. The peer whose 
request is rejected could apply an unplanned re-negotia- 
tion after the winner of the „bully u process has completed 
its negotiation. Ah example for this case is the simulta- 

25 neous detection and re-negotiation reaction of the in- 

volved peers to a QoS violation. 

♦ Since the generated session ID contains also a randomly 
generated number (together with the IP, port, etc. infor- 

30 mation) for the identification, it is not to be expected 

that some of the peers would always be „winners" and some 
always „losers". 

Finally, the aforementioned contention resolution process 
35 also applies to the case of a negotiation procedure colliding 
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with a pre-negotiation procedure or even a lease-renewed pro- 
cedure as well as for the collision of a pre-negotiation pro- 
cedure with a lease-renewed procedure. 

5 The model described in the previous subsections represents 
the static definition of the E2ENP UA FSM 106. At runtime, 
the E2ENP UA 128 shall associate a specific E2ENP session 
with an object representing it. This object - the Session - 
shall contain any information related with the given E2ENP 
10 instance : most notably, a pointer to the current state and 
the instance of all the condition variables defined in the 
model above. 

A thread of execution shall dynamically be associated with 
15 each of these Session objects: either created on demand, or - 
better - picked up from a thread-pool (potentially with lazy 
initialization) . 

♦ This version of the E2ENP is based on the SIP protocol 
20 specification described in [Rosl] . If at later time an- 
other session level protocol or a more generic, approach is 
chosen, the FSM 106 should be reworked in order to mask 
the corresponding changes from applications 130 or QoS 
Brokers 130, thanks to the E2ENP UA API 101b abstraction. 

25 This means that the interaction of the FSM 106 with the 

E2ENP UA API 101b Service User is a de sign- invar i ant . 

♦ The use of the SIP MESSAGE method is tentatively indicated 
in Fig. 30. Alternatively, the SIP OPTIONS .method could be 

30 used. In the scope of the underlying invention, only the 

latter is exposed by the SIP UA Generic API 101c since the 
use of the former for implementing the FSM 106 model de- 
scribed below is still being investigated. 
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In order to avoid that entities interfacing with the E2ENP 
UA 128 (e.g. the E2ENP UA 128 Service Users, the SIP UA 
110, and E2ENP management entities 102) directly invoke 
E2ENP UA 128 incoming primitives in response to E2ENP UA 
128 outgoing primitives before the E2ENP UA 128 has ever 
had a chance to reach a stable state configuration, the 
E2ENP UA 128 is by design always loosely coupled with the 
aforementioned external entities. Another reason for this 
design choice is the possibility that otherwise there 
would-be a non-null probability J:hat .the en ( titie,s, .inter- 
facing with the E2ENP UA 128 might block indefinitely a 
E2ENP UA thread. 

♦ This means that the E2ENP UA 128 shall enforce one incom- 
15 ing message queue for the whole E2ENP UA FSM 106 as well 

as an outgoing message queue for each of the interfaces 
IF1, IF2, and IF3. The reason for the latter queues is due 
to the fact that the E2ENP UA 128 , which is a software 
component, can not make t any assumption on the way applica- 
20 tions 130 would handle primitives thrown by the UA. 

♦ This approach is not necessary for IF4 and IF5 since the 
Parser 112 and the Factory 114 are designed as thread- 
safe, re-entrant libraries accessed by the E2ENP UA FSM 

25 106 via synchronous interfaces. 

♦ Concurrent instances of the E2ENP UA FSM 106 are handled 
with the aid of a thread-pool. 

30 The E2ENP UA FSM 106 depends on the following components:. 

♦ the E2ENP UA API 101b, exposing the E2ENP functionality as 
implemented by the FSM 106, 
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♦ the Parser API lOld, used for accessing services dealing 
with the parsing of session descriptions contained in re- 
ceived SIP messages, 

♦ the Factory API lOle, used for accessing services dealing 
5 with the creation of session descriptions to be inserted 

in outgoing SIP messages/ 

♦ the SIP UA Generic API 101c, used for accessing SIP serv- 
ices, 

♦ the E2ENP Management API 101a, used for accessing services. 
10 dealing with the overall . E2ENP UA 128 management function- 
ality, and 

♦ the Cache 104, used for storing and correlating identifi- 
ers of a given session. 

15 The E2ENP UA FSM model is described in Figs. 30, .31, 32, 34, 
and 36 in terms of UML State Charts and can.be implemented by 
using various well-known design patterns* In any case, as in- 
dicated in Fig, 1, the FSMs 106 are associated at runtime 
with instances of the applied framework or design pattern to 

20 implement the model. Each instance is associated with a spe- 
cific SIP phase [ReqSpec] , i.e. pre-negotiation, lease re- 
newal, or negotiation. Re-negotiations run on the same in- 
stance as the underlying session established with the corre- 
sponding negotiation. 

25 

In order to handle the life cycle of an FSM 106 instance 
(creation,' activation, deactivation, and destruction), an FSM 

instance factory 106 (see Fig. 1) is envisioned- This should 

be a singleton object creating instances of the FSM 106 ei- 
30 ther upon invocation of specific E2ENP UA API 101b primitives 
(negotiationReq, prenegotiationReq, renewLeaseReq) or upon 

invocation of specific SIP UA Generic API 101c primitives 
( connect ionlnd, options Ind, messagelnd) . 
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Fig. 37 depicts the MSC for a simple pre-negotiation sce- 
nario, wherein the correlation between the E2ENP UA API 101b 
and the SIP UA Generic API 101c via the E2ENP UA FSM 106 is 
5 highlighted- 
Fig. 38 depicts the MSC for a simple session establishment 
scenario, wherein the correlation between the E2ENP UA API 
101b and the SIP UA Generic API 101c via the E2ENP UA FSM 106 

10 is highlighted. In the presented scenario, the conf irmation 
of resource reservation completion from the Offerer side ar- 
rives before the same happens at Answerer side. Likewise, it 
is assumed that the resource reservation process succeeds in 
reserving, exactly the amount of the originally requested re- 

15 source. 

In the following subsection, the E2ENP UA factory 108 shall 
briefly be described. 

20 The E2ENP UA factory 108 is a management functionality mod- 
eled according to the ^abstract factory" design pattern de- 
scribed in [Gam] for instantiating a specific E2ENP UA 128 
implementation using an implementation- independent interface. 

25 This entity handles the instantiation of all the classes de- 
scribed in the previous sections required to create an in- 
stance of the E2ENP UA 128. More • specif ically, the E2ENP UA 
factory 108 creates the following entities: 

30 ♦ an E2ENP UA FSM factory, which in turn creates the E2ENP 
UA FSM static structure, 

♦ the FactoryFactory 120, which in turn creates the E2ENP 
Factory 114, 

♦ the ParserFactory 118, which in turn creates the E2ENP 
35 Parser 112, and 
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♦ the Cache 104. 

Thereby, said E2ENP UA factory 108 depends on the following • 
components : 

♦ the application 130 and/or middleware 130, which may di- 
rectly call the E2ENP UA factory 108, alternatively a man- 
agement entity 102. 

♦ the E2ENP UA FSM 106, whose factory is created by the 
given concrete E2ENP UA factory implementation. 

♦ the Factory 114 and Parser 112, whose factories are cre- 
ated by the given concrete E2ENP UA factory implementa- 
tion. 

♦ the Cache 104, which is created by the given concrete 
E2ENP UA factory implementation. 

The E2ENP UA factory 108 has been designed by using the ob- 
ject-oriented paradigm. Thus, it is hereby described by using 
the Unified Modeling Language (UML) . 

In the following, the E2ENP object configuration parameters 
shall briefly be summarized. 

The E2ENP UA 128 and its sub-components (FSM 106, Parser 112, 
Factory 114, Cache 104) are configurable elements. The ini- 
tial configuration should consider the specific features of 
the peer using the E2ENP UA 12 8. 

The E2ENP UA 128 should be initialized with the following pa- 
rameters : 

♦ The E2ENP UA FSMs 106 are initiated with specific time- 
outs for the crucial states, where prompt decisions about . 
the performance should be taken. The length of the time- 
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outs depends on the specific underlying protocol of the 
E2ENP UA 128 and- on the performance features of the re- 
spective peer. The time-outs of the different devices and 
networks may vary with a certain extent. The implementers 
should consider these variations by defining the time- 
outs. 

♦ The Cache 104 does not need any configuration parameters 
and is initiated by the E2ENP UA 128. 

♦ The Parser 112 and the Factory 114 are respectively con- 
figured with the used underlying protocol type and their, 
respective class name. They are initiated by means of the 
E2ENP UA 128. 

The configuration of the E2ENP UA 128 and its respective com- 
ponents can be performed either manually with the aid of a 
Graphical User Interface (GUI) or can be preset with configu- 
ration parameters read from a configuration file. 

Conceirning the E2ENP UA FSM 106, the following parameters are 
configurable: 

♦ Thread-pool configuration parameters: 

* Maximum number of threads in the E2ENP thread-pool. 

* Selector indicating whether the pool should have a lazy 
initialization (i.e. threads are created only when re- 
quired) . 

• Selector indicating whether thread-pool optimization 
is required (only when lazy initialization is en- 
forced) . For optimization reasons, the pool might be 
reconfigured at runtime based on the actual pool us- 
age. 
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=> Thread-pool optimization timer: Upon expiration of 
such timer, the optimization process should be ap- 
plied (i.e. unused threads released). 

♦ Timers (cf . Tab. 19) . 

♦ Mutex : 

* Timer for detecting potential indefinite lock of the. 
mutex, eventually with the aid of a low-priority in- 
stance of the FSM 106 (cf . TM in Tab. 19) . 

* The number of attempts to get said mutex is limited by a 
maximum number (Max-Attempts) . 

The SIP UA implementation 110 shall allow configuring at . 
least the following parameters: 

♦ Underlying Session Protocol: This is the protocol used by 
E2ENP for carrying its meta-messages (SIP, RMI, socket) . 
In future specifications of E2ENP, other session-layer 
protocols could be used (e.g. H323) . 

♦ Underlying Transport Protocol: The type of transport pro- 
tocol to be used by SIP. In future specifications, this , 
parameter might become a configuration parameter of the 
SIP UA 110 itself. 

The following subsection provides information about the deci- 
sion to make communication between the E2ENP UA 128 and the 
Parser 112 respectively the Factory 114 synchronous. In this 
connection, the E2ENP UA 128 shall support multiple concur- 
rent instances of the E2ENP UA FSM 106. In order to avoid an 
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unbounded usage of OS resources, the E2ENP UA 128 shall en- 
force a thread pool. 

Communication between the E2ENP UA 128 and the Parser 112 re- 
spectively Factory 114 could also be asynchronous, e.g. im- 
plemented by an active request interface and a passive con- 
firmation interface. This. option is not used within the scope 
of the underlying invention because some gain in performance 
and flexibility is opposed by much more complicated state 
models for the FSMs 106 of the E2ENP UA 128. 

One consequence of this decision is that the E2ENP UA 128 
and the Parser 112 (also the Factory 114) communicate syn- 
chronously, thus having to share a common address space, 
which in most circumstances is a reasonable. assumption. An- 
other consequence 6f this decision is that both the Parser- 
Factory and the FactoryFactory have to be designed as thread- 
safe, re-entrant libraries. 

Due to the discussion above, it is decided that communication 
between the E2ENP UA 128 and the Parser 112 as well as the 
Factory 114 is synchronous. 

In conclusion, the main advantageous differences between the 
underlying invention and the state of the art shall be empha- 
sized. Briefly summarized, the main benefits of the proposed 
approach consists in 

- a QoS pre-negotiation with a lease-based management of pre- 
negotiated information, QoS negotiation, and QoS re-nego- 
tiation, and 

- a resource reservation and/or release coordination offered 
by the E2ENP UA 128. 
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Moreover, the information to be negotiated (capabilities, ap- 
plication-level QoS Contracts, network-level QoS Contracts, 
stream-level adaptation paths, and stream-group-level adapta- 
tion paths) can be expressed in an interchangeable format in 
5 such a way that heterogeneous applications 130 and/or middle- 
ware 130 can easily agree on a reference model, which said 
applications 130 and/or said middleware 130 can then use for 
dynamically configuring Finite State Machines 106 (FSMs) in 
order to orchestrate local, peer, and network resources ac- 
10 cording to the preferences and profiles of the respective 

user, policies of the respective systems and network provid- 
ers in a coordinated manner among a plurality of heterogene- 
ous applications 130 and middleware 130 used by various 
peers . 

15 

Finally, said E2ENP UA 128 can be used for any session-layer 
protocol and session description language, a plurality of ap- 
plications 130 and different types of middleware 130. 



P 26921 EP and P ZbVZZ EP 

92 



Table A: Used Abbreviations 



Abbr. 


Brief Explanation 


API 


Application Programming Interface 


ASCII 


American Standard Code for Information Interchange 


E2ENP 


End-to-End Negotiation Protocol 


FSM 


Finite State Machine 


IF<X> 


Interface <X> 


IP : 


Internet. Protocol 


IPv6 


IP version 6 


LAN 


Local Area Network 


MIME 


Multi-Purpose Internet .Mail Extensions . 


MSC 


Message Sequence Chart (UML) 


OS I 


Open Systems ..Interconnection 


QoS 


Quality of Service 


RMI 


Remote Method Invocation 


RPC 


Remote Procedure Call 


SDP 


Session Description Protocol 


SDPng 


Session Description Protocol (next generation) 


SIP 


Session Initiation Protocol 


UML 


Unified Modeling Language 


XML 


Extensible Markup Language 
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1. A system offering an Application Programming Interface 
(101b) for multi-stream multimedia applications running on at 
least two registered end peers participating in a mobile 
telecommunication session and/or intermediate components 
(130) being connected to a mobile network, said system (128) 
providing guaranteed end-to-end quality and resource capa- 
bilities using the concept of concatenated E2ENP phases and 
being adapted to provide 

- a pre-negotiation of a multiplicity of alternative capa- 
bilities and QoS Contracts, 

- management of leased pre-negotiated information, 

- session establishment between said end' peers with negotia- 
tion of a multiplicity of alternative capabilities and/or 
QoS Contracts, and 

- a fast, dynamic re-negotiation of the end-to-end quality 
and capabilities, 

wherein the information to be negotiated is expressed in an 
interchangeable format so as to allow said multi-stream mul- 
timedia applications to agree on a specific reference model 
of the negotiated information, which can then be used for dy- 
namically configuring Finite State Machines (106) to orches- 
trate local, peer, and network resources according to the 
preferences and profiles of the respective user. 

2. A system according to claim 1, 
characterized in that 

said system (128) is internally decomposed into a set of Fi- 
nite State Machines (106) coordinating the internal processes 
and Application Programming Interfaces (lOla-e) . 
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3. A system' according" to claim" '2, 
characterized in that 

said multi-stream multimedia applications and/or said inter- 
mediate components (130) use said Finite State Machines (106) 
for a dynamic configuration. 

4. A system according to anyone of the preceding claims, 
characterized in that 

it is designed to support multiple concurrent users. 

5. A system for establishing a session between two entities 
in a telecommunications network, said unit (128) comprising 
the following Application Programming Interfaces (APIs) : 

- a Management API (101a) representing an interface (IF1) be- 
tween the unit. (128) and an entity (102) managing it, 

- an API (101b) representing an interface (IF2) between the 
unit (128), middleware (130) and/or an application using 
services offered by the unit (128), 

- a User Agent Generic API (101c) representing an interface 
(IF3) between the unit (128) .and a User Agent (110) of a 
session-layer protocol. 

6. A system according to anyone of the preceding claims, 
characterized by 

a two-stage E2ENP Cache (104) for managing negotiation object 
identifiers in order to decouple the identification scheme of 
a specific application and/or middleware (130) from the one 
specified for the E2ENP by non-persistently storing and re- 
trieving 

- E2ENP session identifiers referring to the respective mo- 
bile telecommunication session, 

- the E2ENP session identifiers referring to the respective 
Service Provider (110) handled by the Finite State Machine 
(106) of the unit (128), and 
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- the E2ENP session identifiers referring to the respective 
Service User (130) handled by any application and/or mid- 
dleware (130) using the services offered by said unit... 
(128) . 

7. A system according to anyone of the preceding claims, 
characterized in that 

the unit (128) is adapted to 

- pre-cache information during the execution of a given E2ENP 
pre-negotiation or negotiation procedure, wherein the pre- 
cached data remains cached for future reference during a 
later E2ENP session once the given procedure has been sue-, 
cessfully completed, and 

- to cache information which can be applied as a reference to 
data, which has already been (pre-) negotiated among the, end 
peers, during a new E2ENP pre-negotiation or negotiation 
procedure . 

8. A system according to anyone of the preceding claims, 
characterized by 

E2ENP session-layer protocol APIs (lOla-e) being independent 
of the actually used session-layer protocol and the session . 
description protocol implementations. 

9. A system according to anyone of the preceding claims,, 
characterized by 

a Factory API (lOle) representing an interface (IF5) between 
the unit (128) and a Factory instance (114) used for encoding 
an E2ENP session description. 

10. A system according to anyone of the preceding claims, 
characterized by 

a Parser API (lOld) representing an interface (IF4) between 
the unit (128) and a Parser instance (112) needed for decod- 
ing an E2ENP session description. ' 
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11. A system according to anyone of the claims 9 and 10, 
characterized in that 

the Parser instance (112) and the Factory instance (114) can 
be configured independently by using the same protocol. 

12. A system according to anyone of the preceding claims, 
based on a novel usage of the Session Initiation Protocol 

(SIP) in conjunction with extensions of the Session Descrip- 
tion Protocol (SDP) or Session Description Protocol - Next 
Generation (SDPng), respectively. 

13. A system according to claim 12, 
characterized in that 

the session-layer protocol and the Session Description Proto- 
col (SDP) or Session Description Protocol - Next Generation 
(SDPng), respectively, are independently configurable. 

14. A negotiation method providing guaranteed end-to-end 
quality and resource capabilities for multi-stream multimedia 
applications running on at least two registered end peers 
participating in a mobile telecommunication session and/ or 
intermediate components (130) being connected to a. mobile 
network to dynamically adapt to changes in transmission qual- 
ity, which is based on extensions of the End-to-End Negotia- 
tion Protocol (E2ENP), said method providing 

- a pre-negotiation of a multiplicity of alternative capa- 
bilities and- QoS Contracts, • 

- management of leased pre-negotiated information, 

- session establishment between said end peers with negotia- 
tion of a multiplicity of alternative capabilities and/or 
QoS Contracts, and 

- a fast, dynamic re-negotiation of the end-to-end quality 
and capabilities 
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using the concept of concatenated E2ENP phases, 
characterized by the step of 

expressing the information to be negotiated in an inter- 
changeable format so as to allow said multi-stream multimedi 
applications to agree on a specific reference model of the 
negotiated information, which can then be used for dynami- 
cally configuring Finite State Machines (106) to orchestrate 
local, peer, and network resources according to the prefer- 
ences and profiles of the respective user. 

15. A negotiation method according to claim 14, 
characterized in that 

the resource reservation coordination process is based on a 
multi-phase call-setup mechanism that makes network QoS and 
security establishment a precondition to sessions initiated 
by the session-layer protocol and described by a session de- 
scription protocol implementation, wherein network resource 
reservation mechanisms are deployed before the session is 
started, 

wherein Indication (ind) and Confirmation (Cfm) primitives, 
which are invoked by the unit (218) to the registered client 
side of the middleware (130) in order to respectively indi- 
cate the arrival of a particular message exchange or confirm 
the conclusion of a given message exchange/ are an integral 
part of the E2ENP and mapped to a E2ENP „qosdef" section 
(1300), which either specifies capabilities of a peer or de- 
fines validated QoS contracts that have been validated by en- 
tities using the unit (128), and its corresponding negotia- 
tion process. 

16. A negotiation method according to anyone of the claims 14 
and 15, 

characterized by 

a mandatory synchronization of the reservation processes be- 
tween different peers according to an ^Economy Principle-. 
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17. A negotiation method according to .anyone of the. claims 14 
to 16, 

characterized in that 

in case no network resource .reservation is conducted by the 
end peer at the Offerer side, the unit (128) of another end 
peer acting as an Answerer determines this case by examining 
the preconditions made by the Offerer and correspondingly en- 
ables the Answerer to transparently deal with resource reser- 
vation coordination. 

18. A negotiation method according to anyone of the claims 14 
to 17, 

characterized by the step of 

allowing both end-to-end and segmented reservations, wherein 
network resource reservation is done locally on beforehand 
with no cost and/or major impact on session establishment. 

19. A negotiation method according to anyone of the claims 14 
to 18, 

characterized in that 

in case a multi-stream multimedia application or QoS Broker 
(130) wishes to execute a „pre-reservation" of network re- 
sources, the E2ENP signaling gives the right timing to said 
application or middleware (130) , respectively, thereby in- 
forming it when the resource reservations at all sides have 
been accomplished. 

20. A negotiation method according to anyone of the claims 14 
to 19, 

characterized by 

a new E2ENP syntax which allows that E2ENP addresses (600) 
identifying different E2ENP users, which are passed on by the 
applied pre-negotiation and negotiation primitives and mapped 
to the specific syntax used by the underlying session-layer 
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protocol that is used for piggybacking E2ENP information, are 
independent of said session-layer protocol and/or. the respec- 
tive transport protocol used underneath by the unit (128) . 

21. A contention resolution method used for a negotiation 
method according to anyone of the claims 14 to 20, which is 
applied in case of two peers initiating E2ENP phases at the 
same time, 

wherein the E2ENP UA (128) does not only include the session 
identifier sent by an Offerer but also a hash thereof as a 
substitute for said session identifier in any subsequent ses- 
sion-layer protocol message which takes the IP address of the. 
computing unit where the E2ENP UA (128) is active into ac- 
count and a time stamp, which is applied whenever a negotia- 
tion or pre-negotiation phase is initiated. 

22. A contention resolution method according to claim 21, 
characterized in that 

in case two peers are not already involved in multimedia ses- 
sions, each peer compares the hash it has generated with the 
one received from the peer, and the peer with the biggest 
value is automatically chosen as Offerer and thus proceeds 
with the pre-negotiation or negotiation phase as such, 
whereas the other peer automatically moves to the Answerer 
mode. 



23. A contention resolution method according to claim 21, 
characterized in that 

in case two peers are already involved in multimedia ses- 
sions, the peer whose request has been rejected applies an 
unplanned re-negotiation procedure after the peer whose re- 
quest has been accepted has completed its negotiation proce- 
dure. 
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24. A telecommunications network, . 
characterized in that 

said telecommunications network comprises an system (128) ac- 
5 cording to anyone of claims 1 to 13. 

25. A computer software program product, 
characterized in that 

said computer software program product implements a system 
10 (128) according to anyone of claims 1 to 13 when running on a 
mobile terminal in a. wireless network environment. 
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The underlying invention generally relates to the field of 
mobile computing in a wireless mobile networking environment 
with distributed multimedia applications (130). More specifi- 
cally, it is directed to the field of Quality-of-Service 
(QoS) management for adaptive real-time services running on 
mobile devices and an End-to-End Negotiation Protocol (E2ENP) 
based on a novel usage of the Session Initiation Protocol 
(SIP) in conjunction with extensions of the Session Descrip- 
tion Protocol - Next Generation (SDPng) and the Extensible 
Markup Language (XML) for defining user profile and terminal 
capability information which allow to enforce and use hierar- 
chical QoS Contract specifications. 

Thereby, said End-to-End Negotiation Protocol (E2ENP) is ap- 
plied to derive negotiable information, which enables a pre- 
negotiation, fast negotiation and a fast, dynamic re-negotia- 
tion of the end-to-end quality and capabilities for a tele- 
communication session, for multiple configurations of two or 
a multiplicity of end peers and/or intermediate components in 
a consistent, reliable, and incremental way by enabling the 
mobile applications to efficiently and timely react to QoS 
violations. Furthermore, the invention pertains to the con- 
cept and realization of a novel E2ENP User Agent (110) which 
encapsulates the signaling part of E2ENP . Said E2ENP User 
Agent (110) expresses the information to be negotiated in an 
interchangeable format in such a way that heterogeneous ap- 
plications can easily agree on a reference model, which can 
then be used for dynamically configuring Finite State Ma- 
chines (106) to orchestrate local, peer, and network re- 
sources according to the preferences and profiles of the re- 
spective user in a coordinated manner. 

FIG. 1 
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Table B: Depicted Features and their Corresponding 
Reference Signs 
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I Technical Feature 



block diagram showing the applied architecture for the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) according to the underlying invention 



E2ENP Management API (= interface IF1) between the E2ENP 
UA Factory 108 and the Management Entities 102 
E2ENP UA API (= interface IF2) between the E2ENP UA 128 
and any application 130 or middleware 130 using the 
services offered by said E2ENP UA 128 



SIP UA Generic API (= interface IF3) between the E2ENP 
UA FSM 106 and the carrier protocol UA 110 (SIP, RMT, 
etc.) 

Parser API (= interface IF4) between the E2ENP UA FSM 
106 and the implemented Parser 112 
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104 



108 



110 



Factory API (= interface IF5) between the E2ENP UA FSM 
106 and the implemented Factory 114 

E2ENP Management Entities of the E2ENP architecture 100 



Cache API between the Cache 104 and the K2ENP UA FSM 106 



two-stage Cache of the E2ENP architecture 100, connected 
to the Finite State Machine (FSM) 106 of the E2ENP User 
Agent (UA) 128 

Finite State Machine (FSM) applied to the E2ENP User 

Agent (UA) 128 of the E2ENP architecture 100 

E2ENP UA generation factory of the E2ENP architecture — 
100 

SIP-based E2ENP UA generation factory of the E2ENP 

architecture 100 



placeholder ror the implementation of the carrier proto - 
col (SIP, rmi, etc.) user Agent (UA) , also referred to 
as Service Provider 



SIP user Agent (UA) use d for the UA implementation 110 
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No. 


Technical Feature 




of the carrier protocol within the applied E2ENP 
architecture 100 according to the first implementation 
ex amp ± e tuu 


110b 


Java Remote Method Invocation (RMI) -based User Agent 
(UA) used for the UA implementation 110 of the carrier 
protocol within the applied E2ENP architecture 100 
according to the second implementation example 300 


HOC 


socket-based User Agent (UA) used for the UA 
implementation -lia of • the • carrier protocol* within* the 
applied E2ENP architecture 100 according to the third 
implementation example 400 


112 


placeholder for the implementation of the applied Parser 


112a 


SDPng Parser used for the Parser implementation 112 of 
the applied E2ENP architecture 100 according to the 
first implementation example 200 


112b 


Dummy Parser used for the Parser implementation 112 of 
the applied E2ENP architecture 100 according to the 
second implementation example 300. The Dummy Parser is 
used together with the Java RMI based UA 110b. 


112c 


Dummy Parser used for the Parser implementation 112 of 
the applied E2ENP architecture 100 according to the 
third implementation example 400. The Dummy Parser is 
used together with the socket based UA 110c. 


1 "I A 

114 


placeholder for the implementation of the applied 
Factory 


114a 


SDPng Factory used for the Factory implementation 114 oT 
the applied E2ENP architecture 100 according to the 
first implementation example 200 


114b 


Dummv Factorv used for the Factory i mnl ^m^n-h ^-h i nn 1 1 a j^«f 
the applied E2ENP architecture 100 according to the 
second implementation example 300. The Dummy Factory is 
used together with the Java RMI based UA 110b. 


114c 


Dummy Factory used for the Factory implementation 114 of 



P 26148 EP and P 26149 EP 



Technical Feature 



the applied E2ENP architecture 100 according to the " 
third implementation example 400. The Dummy Factory is 
used together with the socket based UA 110c. 



Generation factory of the carrier protocol User Agent 
(UA) implementation 



116b 



JSIP agent 110a generation factory for the carrier 

protocol User Agent 110 for SIP according to the first 
implementation example 200 



RMI agent 110b generation factory for the carrier 

protocol User Agent 110 for Java RMI according to the 
second implementation example 300 



Socket-based agent 110c generation factory for the' 
carrier protocol User Agent 110 for socket-based 
connections according to the third implementation 
example 400 



118a 



Generation factory of the applied Parser implementation 
112 



SDPng Parser 112a generation factory (Parser Factory) of 
the applied Parser 112 according to the first 
implementation example 200 



Dummy Parser 112b generation factory (ParsferFactory) of 
the applied Parser 112 according to the second 
implementation example 300 



.20 



Dummy Parser 112c generation factory (ParserFactory) of " 
the applied Parser 112 according to the third 
implementation example 400 



Generation lactory of the" applied Factory implementation 
114 

SDPng Factory 114a generation factory (FactoryFactory) 

of the applied Factory 114 according to the first 
implementation example 200 

Dummy Factory 114b generation factory (FactoryFactory) 

of the applied Factory 114 according to the second 
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implementation example 300 


120c 


i^uiiuuy rdtuory J.14C generation tactory (FactoryFactory) 
of the applied Factory 114 according to the third 
implementation example 400 




uava casea s±f stacx CJSIP) applied as a component of i 
the said SIP User Agent (UA) 110a 


124a 


Remote Method Invocation (RMI) skeleton of the Java RMI- 
based User Agent (UA) 110b according to the second 
implementation .example 300— . . 


124b 


Remote Method Invocation (RMI) stub of the Java RMI- 
based User Agent (UA) 110b according to the second 
implementation example 300 


126a 


TX socket of the socket-based User Agent (UA) 110c 
according to the third implementation example 400 used 
for transmitting strings or objects 


126b 


RX socket of the socket-based. User Agent (UA) 110c 
according to the third implementation example 400 used 
for receiving strings or objects 


126c 


Adapter of the socket-based User Agent (UA) 110c 
according to the third implementation example 400 used 
for receiving and/or transmitting strings or objects 
using the said sockets 126a+b 


128 


combined unit comprising said Cache 104-, said E2ENP UA 
tSM 10b, and said E2ENP UA Factory 108, in the following 
referred to as E2ENP-based User Agent (E2ENP UA) 


130 


multi-session multimedia application or QoS Broker 
(middleware) using the E2ENP UA API 101b to connect with 
the E2ENP UA 128 


200 


first implementation example of the annl ipH arrhiforfnr- Q 
for the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) according to one embodiment of the 
underlying invention using a Java based SIP Stack (JSIP) 
and SDPng Parser and Factory 
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300 


1 second implementation example of the applied 

architecture for the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using Sun's Java Remote • 
Method Invocation (RMI) 


400 


^™»wtaon example of the applied architecture 
ror the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) according to one embodiment of the 
underlying invention using the socked-based User 

gram protocol (UDP) or Transmission Control Protocol 
(TCP) 


500 


uiu. uia„« Jioy^ showing tne org: : mind: : e 2enp package 


502 


E2ENPUSerAgentListener interface within the ~ ~ ~ 

org: :mind: :e2enp package 


504 


Proviaer interface within the org: : mind: : e2enp package 


506 


otfererLx 0 L«n e r mrerrace, generalized to said interface 
listener i>02 within the org: : mind: :e2enp package 


508 


iuiswerer^xstener interface, generalized to said ~ 7 

•interface Listener 502 within the org: : mind: : e2enp 
package 


510 ! 


ManagerProvider interface " ■ : 


512 


ManagerListener interface 


514 | 


class ConfigurationRequest ' — — : : 


516 

"600 f 
"700 T 


class ParserFactoryConfiguration " 

Augmented BacKus-Naur Form (ABNF) of the E2ENP address 
as a Universal Resource Identifier (URI) 

rirst message sequence chart (MSC) showing the pre-nego- 
tiation procedure enabled by the User Agent (UA) 128 of 
the End-to-End Negotiation Protocol (E2ENP) 

class OffererserviceUser, derived from the class 

E2ENPUserAgentListener, implementing the Listener 
interface 502 

=iass OffererserviceProvider, derived trom the class 


"702 f" 

] 

V04 h 
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Provider, which implements the Provider interface 504 


706 


class AnswererServiceProvider, derived from the class 
Provider, which implements the Provider interface 504 


708 


class AnswererServiceUser, derived from the class 
E2ENPUserAgentListener, implementing the Listener 
interface 502 


800 


second message sequence chart (MSC) showing the session 
establishment with a QoS negotiation and resource 
reservation- coordinat±on ^-enabled by* the "User Agent* (UA) 
of the End-to-End Negotiation Protocol (E2ENP) 


900 


UML class diagram showing the org: : mind: : e2enp: : Cache 
sub-package 


902 


class LevelOneCache representing the first level (LI) of 
the two-stage Cache 104 


904 


class LevelTwoCache representing the second level (L2) 
of the two-stage Cache 104 


906 


class LevelOneEntry encompassing methods for storing and 
loading information to/ from the first level (LI) of said 
two-stage Cache 104 


908 


class LevelTwoEntry encompassing methods for storing and 
loading information to/from the second level (L2) of 
said two-stage Cache 104 


1000 


diagram showing the top-level view of an Extensible 
Markup Language (XML) description used for the End-to- 
End Negotiation Protocol (E2ENP) 


1001 


Complex Type definition descType of. the SDPng desc . 
element. The illustration also incorporates the E2ENP 
specific changes made by the redefine mechanism. 


1002 


// e2enp: purpose" child element of the „desc" element. 


1003 


„sdpng:def" child element of the „desc" element. 


1004 


„sdpng:cfg" child element of the „desc" element. 


1005 


„sdpng: constraints" child element of the „desc" element. 


1006 |„sapng:conf" child element of the „desc" element. 
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1100 


magram snowing the XML substitution groups used for the" 

End— "ho— FInH M^rrrit" t sa +• t Dv«+-a«*i /-i-tOT-i-K-rr-k \ 
*- JA *^ wiiu ANcyuLiaLlun rrOuOCOl (E2ENP) 


1101 


^uiupiex lype aeinution descrype of the SDPng desc 
element, ine illustration also incorporates the E2ENP 
ope^xixu cnanges maae oy the redefine mechanism. 


1102 


wcccup.puipu&e cxiiiu element or rne „desc" element. 


1103 


„sdpng:def" child element of the „desc" element. 


1104 


„sdpng:cfg" child element of the „desc>* element. 


1105 


/,»upny .constraints" child element of the „desc" element. 


1106 


„sdpng:conf" child element of the „desc" element. ~ - 


JL 1 KJ t 


„sdpng:d" element, head of the substitution group which 
defines the valid child elements of the „sdpng:def" 
section . 


1108 


„ audio: codec * element, member of the „sdpng:d M 
suDstitution group. 


1109 


„e2enp:qosdef M element, member of the „sdpng:d" 
substitution group. 


inn 

X X X u 


„rtp:pt" element, member of the „sdpng:d" substitution * 
group . 


1111 


„rtp: transport" element, member of the „sdpng:d" 
substitution group. This element in turn is head of the 
,,i transport substitution group. 


1112 

TTD 


„rtp:udp" element, member of the „rtp : transport" '" 
oLujaLiLution group. 

„ video: codec" element, member of the „sdpng:d" 

substitution group. 




-L \J \J 


diagram showing the XML purpose element used for the 
End-to-End Negotiation Protocol (E2ENP) 


1201 


„purpose" element. Can be used to convey additional 
information about the description following in the 
protocol data unit (PDU) . 


"1202 


„e2enp:use" element. Child of the „purpose" section, can' 
be used to indicate referenced sessions. 
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//description element. Can be used to indicate a 
aescrxpLioii triJU. 


1204 


„mediation" element. Can be used to indicate a mediation 

TDT^TT 
FJJU • 


i o n k 


„e2enp : session" element 


1206 


„expires" element 


1300 


diagram showing the XML qosdef element used for the End- 
to-End Negotiation Protocol (E2ENP) 


1300' 


XML qosdef element " • 1 - ■' - « 


1301 


„audio : codec" element. Describes an audio capability of 
the system. 


1302 


„ video : codec" element . Describes an video capability of 
the system. 


1303 


„rtp:pt" element. Can be used to specify a desired 
payload format for a given capability. 


1304 


„e2enp: policy" element. Can be used to specify the 
resource management policy to enforce. 


1305 


;„e2enp: audio" element. Can be used to describe the QoS 
contracts if or audio streams. 


1306 


„e2enp: video" element. Can be used to describe the QoS 
contracts for video streams. 


1307 


„e2enp: control" element. Can be used to describe the QoS 
contracts for control streams . 


1308 


„e2enp:data" element. Can be used to describe the QoS 
contracts for data streams. 


1309 


„rtp:map" element. Can be used to define a mapping . 
between an application level QoS Contract and a specific 
Kir payioaa rormat. 


1310 


„e2enp : contract" element 


1311 


^predicate" element 


1312 


^criterion" element 


1400' 


XML qoscfg element 


1400 


diagram showing the XML qoscfg element used for the End- 
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to-End Negotiation Protocol (E2ENP) 



„e2enp: context" element. Can be used to define ~ 

associations between data streams and thus to express 
time synchronization and/or QoS correlation. Briefly, 
this element defines high level QoS Contracts. 



,e2enp:adapath" element 



,default" element 



1404 
1405 



1406 
1407 



,alt" element 



-event" element 



path" element 
,,comp~ element 



1409 
1500 



1702 



1704 



1802 
1804 



-constraints" element 



par" element 

UML message sequence chart (MSC) showing the interaction 
between the E2ENP User Agent (UA) 128 according to the 
underlying invention and the applied Parser 112 and • 
Cache 104 

UML class diagram showing the general structure: of a 
Document Object Model (DOM) tree 

class Documentor ee, which models the general structure 



of said DOM tree and can therefore be interpreted as the 
document root element 



class DocumentNode aggregated to said class DocumentTree 
1702, which in turn aggregates between 0 and n children, 
thus recursively describin g the tree structure 
uml class diagram showing a structural overview of the " 
Parser implementation 112 using a ^visitor design 
pattern" for traversing the DOMTree 1804 and generating 
a XMLObject 1802 

class XML Object used within the P arser implementation ~ 
112 



class DOMTree, which models the g eneral structure of 
said DOM tree and can therefore be interpreted as the 
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document root element ' 


1806 


class DOMNode aacrreaated to <5airl niasc nriMTrpo ipnzi 


1808 


generic Parser visitor class pVisitor, which visits 

jjcuwccii J. aim IN JJUiiLN vJ (JLfci o 


1810a 


first specialized DOMNode of said class DOMNode 1806 


1 fll On 


in tlx speciaiizea uuiMuNoae or said class DOMNode 1806 


1812a 


first specialized Parser visitor class pVisitor 1, which 
is applied to handle the first derived DOMNode 


1812n 


N-th specialized Parser visitor class pVisitor N, which 
is applied to handle the N-th derived DOMNode 


1900 


UML message sequence chart (MSC) showing the interaction 
between the E2ENP User Agent (UA) 128 according to the 
underlying invention and the applied Factory 114 and 
cacne 104 


2000 


UML class diagram showing a structural overview of the 
Factory implementation 114 


2002 


generic Factory visitor class fVisitor, which visits 
between 1 and N instances of ObjectGraphNode classes 


o n n a 


class ObjectGraphNode used within the Factory 
implementation 114 


2006a 


first specialized Factory visitor class fVisitor 1, 
which is applied to handle the first derived Node 2008a 
of the class ObjectGraphNode 2004 


jLKJyJ on 


N-th specialized Factory visitor class fVisitor N, which 
is applied to handle the N-th derived Node 2008n of the 

place HKt nri^-ry ^r\l^M/\rIrt oftH/t 


2008a 


first specialized Node (subclass) of the class 


2008n 


N-th specialized Node (subclass) of the class 
ObjectGraphNode 2004 


2100 


UML class diagram showing the org: :mind: : sip: : sipApi 
package 


2102 


class management of the org: :mind: : sip: : sipApi package 



P 26148 EP and P 26149 EP 

11 



No. 


Technical Feature 


2104 


class userAgent of the org: : mind: : sip: : sipApi package 


2106 


class registrar of the org: :mind: : sip: : sipApi package 


2107 


class time of the org: :mind: : sip: : sipApi package 


2108 


interface SipListener of the org: :mind: : sip: : sipApi 
package 


2110 


interface SipProvxder of the org: : mind: : sip: : sipApi 
package 


2112 


class SipExpiresHandling of the org: : mind: : sip :: sipApi 
package 


2114 


class SipEndUser of the org: : mind: : sip: : sipApi package 


2200 


UML class diagram showing the 

org: :mind: : sip: : sipApi : :userAgent package 


2202 


interface SipUserAgentListener of the 

org: :mind: : sip: : sipApi: : userAgent package ' 


2204 


interface SipUserAgentServerListener of the 

org: : mind: : sip: : sipApi: : userAgent package, derived from 

the class SipUserAgentListener 2202 


2206 


interface SipUserAgentClientListener of the 

org: : mind: : sip: : sipApi :: userAgent package, derived from 

the class SipUserAgentListener 2202 


2208 


Class SipConnectionReq of the 

org: :mind: : sip: : sipApi : : userAgent package 


2210 


interface SipUserAgentType of the 

org: :mind: : sip : : sipApi : : userAgent package 


2212 


interface SipUserAgentFactory of the 

org : :mind : : sip : : sipApi : : userAgent package 


2214 


class SipUserAgent of the 

org: : mind: : sip: : sipApi :: userAgent package, derived from 
the class SipUserAgentType 2210 


2214a 


class UAClient of the 

org: : mind: : sip: : sipApi: :userAgent package, derived from 
the class SipUserAgent 2214 


2214b 


class UAServer of the 
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org: : mind: : sip: : sipApi : :userAgent package, derived from 

+-V\*a place Q i i^TTc: ckT* Arr^n f* 9014 


2216 


class SipNegotiationModel of the 

org: :mina: . sxp. . sip/ipx. • useiri^geiic pacitdye 


2218 


class SipRegistrationReq of the 

org: :mma: : sip: : sipApi : :user/\genu pacKage 


2220 


class SipRegistrationCfm of the 

org: : mind: : sip: : sipApi : :userAgent package 


2300 


UML class- diagram- showing "the - • 
org: :mind: :sip: : sipApi: : registrar package 


2302 


interface SipRegistrarListener of the 
org: :mind: :sip: :sipApi : :registrar package 


2304 


interface SipRegistrarType of the 

org: :mind: :sip: : sipApi: :registrar package 


2306 


class SipRegistrar of the 

org: :mind: :sip: : sipApi: -.registrar package, derived from 
said class Sip- RegistrarType 2304 


2308 


class SipRegistrationlnd of the 

org: :mind: :sip: : sipApi: -.registrar package 


2310 


class SipRegistrationRsp of the 

org: :mind: : sip: : sipApi :: registrar package . 


2312 


interface SipRegistrarFactory of the 
org: :mind: : sip: : sipApi : : registrar package 


2400 


UML class diagram showing the 

org: :mind: :sip: : sipApi: rmanagement package 


2402 


interface SipManagementListener of the 
org: :mind: :sip: :sipApi: :managemenu package 


2404 


interface SipManager of the 

r^Trrr • • ttit nH • • n • • qi nAr>i i • man a. dement D3.ck3.Q6 


2406 


class SipConf igurationReq of the \ 
org: :mind: :sip: : sipApi: : management package 


2500 


UML class diagram showing the 

org: :mind: : sip: : sipApi :: time package 
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interface SipExpiresType of the 
org: : mind :: sip: :sipApi: :time package 



class SipParseException of the 

org: :mind: : sip: : sipApi : : time package 



class SipExpires of the 

org: :mind: :sip: :sipApi: :time package 



interface SipExpiresFactory of the 
org: :mind: :sip: :sipApi: :time package 



2600 



UML message sequence chart (MSC) showing the ~ ~ 

configuration of the Service Provider and the binding of 
the Service User with said Service Provider 



UML message sequence chart (MSC) showi ng the connection 
establishment between the User Agents of a client and a 
server 



2800 



UML message sequence chart (MSC) showing the OPTIONS 
method used for the End-to-End Negotiation Protocol 
(E2ENP) 



2900 



UML message sequence chart (MSC) showing the connection 
release between the User Agents of a client and a server 



first state transition diagram. for a nested Finite State 
Machine (FSM) showing the mutex-related procedures 
executed in the root state 



3100 



second state transition diagram for a nested Finite 

State Machine (FSM) showing the mutex-related procedures 
executed in the NegOfferer sub-state 



third state transition diagram for a nested Finite State 
Machine (FSM) showing the mutex-related procedures 
executed in the NegAnswerer sub-state 

fourth state transition diagram for a nested Finite 

State Machine (FSM) showing the mutex-related procedures 
executed in the ReNegOfferer sub-state 

fifth state transition diagram for a nested Finite State" 
Machine (FSM) showing the mutex-related procedures 
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executed in trie ReNegAnswerer sub-state 


3500 . 


sixth state transition diagram for the ResvMtx Finite ! 
State Machine (FSM) for allowing multiple requests to 
seize the mutex in a coordinated manner, based on their 
priority 


3600 


seventh state transition diagram for a nested Finite 
State Machine (FSM) showing the mutex-related procedures 
executed in the WaitForCoordDone sub-state 


37.00.. . 


UML. message- sequence- cha-r-t- (MSG)- showing* the pre-nego- 
tiation procedure needed for the correlation of the 
Application Programming Interface (API) of the E2ENP 
User Agent (UA) and the generic Application Programming 
Interface (API) of the SIP User Agent (UA) , thereby 
using the . above-mentiqried Finite State Machine (FSM) of 
the E2ENP User Agent (UA) 


3702 


class OffererSIPServiceUser, implementing the interface 
SipUserAgentClientListener 2206 


3704 


class OffererSIPServiceProvider, derived from the class 
SipUserAgent 2214 


3706 


class AnswererSIPServiceProvider, derived from the class 
SipUserAgent 2214 


3708 


class AnswererSIPServiceUser, implementing the interface 
SipUserAgentServerListener 2204 


3800 


UML message sequence chart (MSC) showing the session 
establishment with the QoS negotiation procedure and the 
resource reservation coordination needed for the 
correlation of the Application Programming Interface 
(API) of the E2ENP User Agent (UA) and the generic 
*^h f t j - 1 ' u-Li-zxi nuyi ciiiuii j_ i ly interlace lAri] or trie SIP User 
Agent (UA) , thereby using the above-mentioned Finite 
State Machine (FSM) of the E2ENP User Agent (UA) 


3900 


Tab. 1: table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 



i 

I 
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4000 



4100 



4500 



4600 



4700 



4800 



For the Application Programming InLexiace (API) applied" 
to the User Agent (UA) of the End-to-End Negotiation 
I Protocol (E2ENP) 

2: taoxe snowing a list or primitives t Q be 
I implemented by the Service User, based on a Java 
I implementation of the Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) 



I Tab. 3: table showing a list ot pnmxtives to be " 

implemented by the Service User acting as an Offerer, 
based on a Java implementation of the Application 
Programming Interface (API) applied to the User Agent 
(UA) of the End-to-End Negotiation Protocol (E2ENP) 

I ra£>. 4: table showing a list of primitives to be 

implemented by the Service User acting as an Answerer, 
based on a Java implementation of the Application 

| Programming Interface (API) applied to the User Agent 
(UA) of the End-to-End Negotiati on Protocol (E2ENP) 

[Tab. 5; table showing the meth ods provided by the " 

^Application Programming Interface (API) of the first 

Cache level 

Tab. 6: table showing the methods provided by~the~ 
Application Programming Interface (API) of the second 
Cache level 



|Tao. 7: table snowing a list of primitives which have to 
be implemented by the Application Programming Interface 
1 (API) of the Parser 



Tab. 8: table snowing a list of primitives which have to 
be implemented for gener ating a specific parser instance 



r— — — _ * j-"oi.auge 

Tab * 9: tah±e sh °"ing * list of p rimitives which have t o 
be implemented by the Application Programming Interface 
1 (API) of the Factory 



| Tab. 10; table showing a list of primitives which have 
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to be implemented for generating a specific factory 
instance 


4900 


Tab. 11: table showing the methods provided by the well- 
known factory-factory class E2ENPContentHandlerFactory 


5000 


Tab. 12: table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 
of the generic Application Programming Interface (API) 
applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) 


5100 


Tab. 13: table showing a list of client-side-specific 
primitives implemented by the Service User, based on a 
Java implementation of the generic Application 
Programming Interface (API) applied to the User Agent 
(UA) of the End-to-End Negotiation Protocol (E2ENP) 


5200 


Tab. 14: table showing a list of server-side-specific 
primitives implemented by the Service User, based on a 
Java, implementation of the generic Application 
Programming Interface (API) applied to the User Agent 
(UA) of the End-to-End Negotiation Protocol (E2ENP) 


5300 


Tab. 15: table showing a list of both client-side- and 
server-side-specific primitives implemented by the 
Service User, based on a Java implementation of the . 
generic Application Programming Interface (API) applied 
to the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) 


.5400 


Tab. 16:. table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 
of the generic Application Programming Interface (API) 
applied to tne User Agent (UA) or the End— to— End 
Negotiation Protocol (E2ENP) 


5500 


Tab. 17: table showing a list of primitives implemented 
by the Service User, based on a Java implementation of 
the generic Application Programming Interface (API) 
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applied to the User Agent (UA) of the End-to-End ~ 

Negotiation Protocol (E2ENP) 


5600 


Tab. 18: state transition table showincr a survev of 
applied exception events 


5700 


Tab. 19: table showing the applied timers applied to the 
End-to-End Negotiation Protocol (E2ENP) according to the 
underlying invention 



/too 



P specific logic 



110. 




IP-based version 
E2ENP logic 




10TB 



IF2:E2ENPUAAPI 



luua 



128,/M 



>rprets objects | 
is strings containing 
SDPng paytoads 



110a. 




SDPng 
Factory 
factory 

m T20a 



la 

> IF1.-E2ENP 
Management API 




3oo 




wo 



-based version I 
> logic 



irets objects . 
afn objects to (desse- 
rts Bze 




One can later plug-in 
module for respectively 
pre-processing the data 
to send over RM1 /post- 
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public void bindReqtOffererServiceUser oSu, AnswererServiceUser aSu, int spld) ™^ 

Binds the given Service User's event listeners to the given E2ENP UA. 
public void regisfrationReqdnt spld, int serviceUserld, java.lang.String user, 

java.lang.Object info) 

Registers a user with the UA and optionally with a remote registrar, 
public void preNegotiationReq(java.lang.String from, java.lang.String to, int serviceUserld, 

java.Iang. Object offer) 

Initiates a pie-negotiation phase, 
public void preNegotiationRspf int serviceProviderld, java.lang.Object answer) 

Answers to an incoming request from the peer for pre-negotiation. 
public void renewLeaseReqtjava.lang.String user, int servicellserld, java.lang.Object offer) 

Initiates a pre-negotiation information lease refresh, 
public void renewLeaseRsp(int serviceProviderld, java.lang.Object answer) 

Answers to an incoming request from the peer for pre-negotiation information lease refresh, 
public void bookNegotiationReq(java.lang. String user, int servicellserld, int priority) 

Before initiating the negotiation phase, this primitive allows the Service User to book the 

mutually exclusive use of the resource reservation process, with respect to concurrent 

instances of Service Users, 
public void negotiationReqfjava.tang. String from, java.lang.String to, int serviceUserld, 

int serviceProviderld, java.lang.Object offer) 

Initiates a negotiation phase, 
public void negotiationStatusRsptint serviceProviderld, java.lang.Object message) 

Generates an intermediate signaling daring negotiation in response to a peer's signaling. " 
public void bookReNegotiationReq(int serviceUserld, int priority) 

Before initi a t i n g the re-negotiation phase, this primitive allows the Service User to book the 

mutually exclusive use of the resource reservation process, with respect to concurrent 

instances of Service Users. In this case, the serviceProviderld must be specified, 
public void reNegotiationReqt int serviceProviderld, boolean isPlanned, 

java.lang.Object offer) 

Initiates a re-negotiation phase, 
public void reNegotiationRsp(int serviceProviderld, java.lang.Object answer) 

Answers to an incoming request from the peer for re-negotiation, 
public void reNegotiationStatusRsp(tnt serviceProviderld, java.lang.Object message) 

Generates an intermediate signaling during re-negotiation in response to a peer's signaling, 
public void startReservationRspfmt serviceProviderld, java.lang.Object result) 

Notifies that the Service User has completed both local and network resource reservation, 
public void releaseReq(int serviceProviderld, java.lang.Object message) 

Release the given phase (during pre-negotiation and lease renewal) or the overall session, 
public void releaseRsp(int serviceProviderld, java.lang.Object message) 

Replies to a request from the peer to release the given phase (during pre-negotiation and lfease 

renewal) or the overall session, 
public void resetReqttnt serviceUserld, int serviceProviderld) 

Resets the given session as an emergency procedure, 
public void resetRsp(int serviceUserld, int serviceProviderld) 

Tab. 1 



public void bindCfm (Boolean result) 

Returns the result of the bindReq primitive. . 
public void registrationCfmOnt serviceUserld, java Jang. String user, java.lang. Object Info) 

Confirms the registration of the given user with the UA and optionally with an external registrar, 
public void preNegotiationlndljava.lang.String from, java.lang.String to, int serviceProviderld, 
java.lang. Object offer) 

Notifies the Service User of a request from the peer to initiate a pre-negotiation phase, 
public void preNegotiationCfm(int serviceUserld, int serviceProviderld, java.lang. Object answer) 

Notifies the Service User of a reply from the peer concerning the given pre-negotiation 

phase. 

public void renewLeaselndfint serviceUserld, int serviceProviderld, java.lang. Object offer) 

' Notifies the Service User of a request from the peer to initiate a pre-negotiation information 
lease refresh. 

public void renewLeaseCfmfint serviceUserld, int serviceProviderld, java.lang .Object answer) 
Notifies the Service User of a reply from the peer concerning the given pre-negotiation 
information lease refresh. 

public void negotiationStatusInd(int serviceUserld, int serviceProviderld, java.lang. Object. message) 
Notifies the Service User of an intermediate signaling during negotiation, in correspondence 
to a peer's signaling. 

public void bookReNegotiationCfmfint serviceUserld, int serviceUserld, boolean isSuccessful) 

Before initiating the re-negotiation phase, this primitive notifies the Service User that the 

EZENP UA has successfully booked the mutually exclusive use of the resource reservation 

process, with respect to concurrent instances of Service Users, 
public void reNegotiationlndOnt serviceUserld, int serviceProviderld/ boolean isPlanned, 

java.lang. Object offer) 

Notifies the Service User of a request from the peer to initiate a re-negotiation phase, 
public void reNegotiationCfm(int serviceUserld, int serviceProviderld, java.lang. Object answer) 

Notifies the Service User of a reply from the peer concerning the given re-negotiation, 
public void reNegotiationStatusInd(int serviceUserld, int serviceProviderld, java.lang. Object message) 

Notifies the Service User of an intermediate signaling during re-negotiation, in 

correspondence to a peer's signaling, 
public void startReservationlndfint serviceUserld, int serviceProviderld, java.lang. Object result) 

Notifies that the Service User that is time to start reservation of both local and network 

resources. 

public void releaselndOnt serviceUserld, int serviceProviderld, java.lang. Object message) 

Notifies the Service User of a request from the peer to release the given phase (during pre- 
negotiation and lease renewal) or the overall session. 

public void releaseCfmfint serviceUserld, int serviceProviderld, java.lang. Object message) 

Notifies the Service User of a reply from the peer concerning the release of the given phase 
(during pre-negotiation and lease renewal) or the overall session. 

public void alertlnd(int serviceUserld, int serviceProviderld) 

Notifies the Service User that a remote peer has called in. 

public void ringBackInd{int serviceUserld, int serviceProviderld) 

Notifies the Service User that the remote peer has been alerted. 

public void congestionlnddnt serviceUserld, int serviceProviderld) 

Notifies the given Service User instance that other higher priority instances are waiting for 
the mutex to be released. The Service User shall pre-empt by rolling -back to the state before 
the negotiation/re-negotiation started, and invoke the release primitive. 

public void failurelnd(int serviceUserld, int serviceProviderld) 

Notifies the Service User that an E2ENP UA internal error occurred, and that the Service 
User shall invoke the release primitive. 

public void abortInd{int serviceUserld, int serviceProviderld, int reason) 

Notifies the Service User that a SEP error occurred, and that the Service User shall simply 
consider the current operation as aborted. A reason is passed as well, indicating one of the 
possible sources of error: 
. 0 - redirection, 

1 - client error \ 



2 - server error, ~ — 55 ! — K5SSSS5= 

3 - network failure. 

public void resetlndfint serviceUserld, int serviceProviderld) 

public void reseta^ 

— — Notifies the Service User of a x^l X figmthe peer concerning the reset of the sessio^ 
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public void bookNegotiationCfm(int serviceUserld. int serviceUserld, boolean isSucoessful) 

Before initiating the negotiation phase, this primitive notifies the Service User that the 
E2ENP UA has successfully booked the mutually exclusive use of the resource reservation 
process, with respect to concurrent instances of Service Users. This primitive is specific of 
the offerer side, whereas the homonymous bookReNegotiationCfmmay be invoked 
•either at the offerer or at the answerer side, 
public void negotiationCfmlint serviceUserld, int serviceProvIderld, java Jang. Object Answer) 
Notifies theService User of ajreplv from the peer concer ning the given negotiation. 
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pubhc void ncgotiationInd«ava.lang.String from: java.lang.String to. Int serviceUserld " " 

mt serviceProviderld, java.lang. Object offer) 

No fifies the Service User that the aegotiation/set gp phase has been comn.^ ^^^^^ 
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public 
LevelOneEntry | 


LevelOneCachccreateEntry (CoreSession session, int serviceProviderld) | 
I Creates a level 1 entry 


assssssgssssxatsssssnsssssssssssssssoTS^ 

public 
LevelOneEntry J 


LevelOneCachagetEntry (int serviceProviderld) | 
Gets a level 1 entry by using the servicejgrovieder ID asjprimary key 


public I 
LevelOneEntry 


LevelOneCache-findEntry (int serviceUserld) s 
Gets a level 1 entry usin# the service user ED as secondary key 


public 
LevelOneEntry. j 


LevelOneCachcfindEntry (java.lang. String from, java.lang. String to) 1 
. . Gets a level 1 entry using the (From, To) SIP address couple as secondary key 


nubiic 
java.util.Vector 


T .evelOneCaclie fjnrfEntrv'Bv'E^gtSessionldfiava Jana .String session! 

Gets the level 1 entries by using the E2ENP Session-ID as secondary key 


niihltf* v/nirt 

puuuu VUIU 


T.«»vf»1fYnc»f 1 arlitffc v-f»m nvplT.nfrv ( Lex/el One Entrv fintrv^ 

Deletes the given entry from the cache 


nuhiiri void 

[ 


Ti k vplflnpr i Ar]ip rl<»ai" 
jucraviiCvAUiviUMU \_/ 

Removes all the entries. 


public void 

1 


LevelOneEntry.putSessionIDGava.lang. String sessionld) 

Puts the E2ENP Session-ID in the entry associated with the given service 
provider ID. 


public 
java.lang. String 


LevelOneEntry.getSessionID 0 1 

Gets the E2ENP Session— ID associated with the given service provider ID 


public void 


LevelOneEntry.putServiceUserlD (int serviceUserld) 

Puts the service user ID in the entry associated with the given service provider ID. f 


public int 


LevelOneEntry.getServiceUserlD 0 

Gets a service user ID ! 


public int 


LevelOneEntry.getServiceP roviderfib 6 1 
Gets, a service provider ID 


j. public void 


LevelOneEntry.putFromAddress (java.lang.String from) 

Puts the SIP From Address associated with the given service provider ID 


( public 

L javaJang. String 


LevelOneEntry. getFromAddress 0 

Gets the SIP From Address associated with the given service provider ID 


1 public void 

1 

L ; 


LevelOneEntry.putToAddress (java-lang.String to) j 
Puts the SIP To Address associated with the given service provider ID 


public . 
[ java.lang. String 


LevelOneEntry.getToAddressO 

Gets the SIP To Addr e s s associated with the given service provider ID 
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LevelTwoEntry 



public 
LevelTwoEntry 



public void 



Creates a level 2 entry 

7™ r '"ill ~ — "frfa 



public void 
public void 



LevelTVoCachclindEntry Gava.lang.String sessionld) 

Gets all thejevcj 2 entries by using the E2 ENP Session- ID as 

LevelTwoCachcremoveEntry (LevelTwoEntry entry)" 
B^^S^M^ cntyv froni the cache 



public 
java.lang. String 



|L^lT^oCache.cI^O 

session-ID in the entry associated with the given service 



public void 

|f T " 

public int 



|I^veiiVoEnti^.ge«essionID"o^ """" — 

1 . y th6 E2ENP Se ssl o n - ID associated with the given service provider tt, 

ILevelTwoEntry.putScrviceUserlD (int serviceUserld) ' 

I 'I* 6 10 SS ^ associated with the given sen dee nm^.. tt. 

|LevelTwoEntiy.getServiceDserID O " W7 mai *> : , 

g Gets a service » g prTr> 
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java.lang.String 


getType ( ) 

Returns an identifier to uniquely specifiy the type of this parser. 


boolean 


isConf inriExpected ( j ava . io . Serializable in) 

Checks all media stream definitions for preconditions (PC), and, if at least one such definition 
las a PC that the offerer is going to carry out reservation, and thus, going to send a 
confirmation to the answerer when done. 


boolean 


i sKeepRe suits Cached ( java .io . Serializable in) 

Extracts information about whether the results of a negotiation of re-negotiations should be 
cached or not 


boolean 


isRingBackExpected ( java. io. Serializable in) 

Checks all media stream definitions and returns true, if any of the streams is going to be 

generated by the answerer. 


java.Iang. Object 


parseFinalResponse ( java „ io • Serializable in) 
Parses a final result message and returns the corresponding status. 


java.lang.Object 


par seLeaseAnswer ( java. io .Serializable in) 

Parses a transport representation of a renew lease answer and returns the corresponding object- 
representation. 


java.lang. Object 


par seLeaseOffer (java. io. Serializable in) 

Parses a transport representation of a renew lease offer and returns the corresponding object* 
representation. 


long 


pars eLease Time ( java .io • Serializable in) 

Parses a transport representation of a lease answer/offer and returns the corresponding lease 
time as a basic long value. 


java.utiLVector 


parseLisfcOfUsedSessionlds (java.io. Serializable in) 

Parses the given input selectively to extract the external representation of the list of referenced 

E2ENP session identifier. 


java.lang.Object 


par seMes sage ( j ava . io • Serializable in) 

Parses content which is mapped over various e2enp primitives/SIP messages. 


java.lang.Object 


par seNegAnswer (java • io .Serializable in) 

Parses a transport representation of a negotiation answer and returns the corresponding object- 
representation. 


java.lang.Object 


parseNegCOffer ( j ava . io . S e rializable in ) 

Parses a transport representation of a negotiation counter-offer and returns the corresponding 
object-representation. 


java.lang.Object 


parseNegOffer (java.io. Serializable in) 

Parses a transport representation of a negotiation offer and returns the corresponding object- 
representation. 


java.lang.Object 


DarsePreNeeAnswer (i ava. io. Serializable in) 

Parses a transport representation of a pre-negotiation answer and returns the corresponding 
object-representation. 


java.lang.Object 


parsePreNegOf f er (java . io . Serializable in) 

Parses a transport representation of a pre-negotiation offer and returns the corresponding 

ohi ect-reriTesentat i on 


java.lang.Object 


parseReNegAnswer ( java.io . Serializable in) 

Parses a transport representation of a re-negotiation answer and returns the corresponding 
object-representation. 


java.lang.Object 


parseReNegCOf f er ( java.io . Serializable in) 

Parses a transport representation of a re-negotiation counter-offer and returns the 

corresponding object-representation. 


java.lang.Object 


par seReNegOf f er ( java.io. Serializable in) 

Parses a transport representation of a re-negotiation offer and returns the corresponding object- 
representation. 


java.lang.Object 


parseReservationResult ( j ava . io . Serializable in) 



Parses a transport representation of a 
object-representation. 



reservation result message and returns the 



parsesessionldt j ava . io . Serializable in) 

itatite* *** SeleCtiVely t0 ***** 48 exteraal mentation of the E2ENP 
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Parser 


createParserQavaJang-String protocollD) j 
Creates a parser instance for the given protocol. *• ( _ _ .. . 


void 


registerParserGava.Iang.String protocollD, java.lang. String parserClassName) j 
Register a parser implementation for the given protocol. j 
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java.io.Serializable 
java.io.Serializable 
java.io.SeiiaHzable 



java.io.Serializable 
java.io.Serializable 



java.io.Serializable 



java.io.Serializable 



java.io.Serializable 
java.io.Serializable 



long 



java.util.Vector 



java.lang.String 



Kw^»v r ^uiauu U Aur a Qnai respo nse i 

createLeaseAnswer ( java . lang. Object in) 
Create the transport representation for a renew answer 

createXeaseOffer(java. lang. Object in) 

Creates the transport representation for a ren^ w» offer 

createMessage ( j a va . Lang . Object in) — 

ZSSZSSjZ* ?*** <*™*°>«*<* is mapped c^v^ ^p 

cxeateNeganswer(java. lang. Object in)" 

Creates the transport representati on for a ne^ ti™, „~ 

createNegCOffer ( java . lang . Object in) 

Creates the transport represen t ation for a ne g otiation connte r-nffi-r 

createNegOf fer ( java . lang . Ob j ect in) 

Creates the transport representation for a negotiation nffi, 
createPreHegAnswex ( j ava . lang . Obj ect in) 
Creates the transport representati on for a pre-ne antiarinn M „. r 
creat e PreNegOffeir(java. lang. Object in) 
Creates the transport repres entation for a p ie-napntiaH,™ offer 
oreateReNeoAnswer TTzTTrZ TT^Z _ fr . _. . - 



createReNegAnswex ( j ava . lang . Object in) 
Creates the transport represent ation for a reneg otiation 

crearetteNegCOf £ et ( j a va . lang . Obj e'ct in ) ! 

n^?,^ ^° rt ^"^ntationfor a coiurtet^offer 

crcateReHcgOffer ( 3 ava. lang. Object in) = 

Creates the transport represent ation for a re-ne anristin., offer 

creates the transport rep resen tation for a rese rvation result m P « g , 

getLeaseTime (javaJang. Object in) ' : —* 

^ ^lease time stored in the internal rep resentation represented by the input 

getListOfUsedSessioixrds (java. lang. obj ect in) — 

Extracts the list of used session IDs stored in the internal representation ren™.^ w. 
the input parameter in. rcpresemauon represented by 



getSessionZd ( j ava . lang . Ob j ect in ) 

^^session ID storedin the interna, representation represented by the input 
getType ( ) 

Returns an identifier to uniquely gecifiy. the ^ r . pfthis facto 
xsKeepResultsCaohedC java . lang. Object in) 
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Facto ry jlcreateFactory Q a va . lang . String p rotoco! ! D) 



4800 



void jlregisterFactoryCiava. lang. String protocollD, java. lang. String factoryClassName) 
1 Registers a factory class forfre given gS^^L 
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abstract Factor 
abstract Parser 
static 

E2ENPCQnt entHanrif prP a ^nn > . 



abstract void 



FeateFactog ( 3 ava . i ang . strlng peotoeolIpT 
Creates a fa ctory instance for the oven protocol 
grearerarser ( Java . Iang . String protocolip ) 
Creates a p arser instance for the pven p mtn^i 
getlnstanca ( ) *~ 



43Q0 



Provides access to the singleton instance of the 
r E2ENPContentHandlerFactory. 

registerFactog ( j ava . Iang . String protocolip 



3 ava. Iang. String factory CI ass Name) 
Registers a f actory class for the given p rotect 



^;i^?;?^? 1 parSerClass Na I ne, javaflang. string 
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Sooo 



void release!) 

Shuts down the given SIP UA. • 
void bindReq(SipEndUser user, SipUserAgentClientListener ssmlc, 
SipUserAgentServerListener ssmls) 

Binds the given user's event listeners to the given SIP UA 
void configureReq(SipManagementUstener sml, SipConfigurationReq conf) 

Configures the given SIP UA. 
void connectionReq(SipEndUser user, int connectionld, SipConnectionReq invitation, 
java.io.Serializable message, java.tang. String mimeContentType) 
Allows generating a request to establish a session, 
void connectionRsp<SipEndUser user, int connectionld, int status, 

java.io.Serializable message, java.lang. String mimeContentType) 
Allows replying to a request to establish a session, 
void connectionStatusReq(SipEndUser user, int connectionld, int type, boolean isMiddle, 
java.io.Serializable message, java.lang. String mimeContentType) 
Allows generating provisional responses, 
void connectionStatusRspiSipEndtlser user, int connectionld, int type, 
java.io.Serializable message, java.lang. String mimeContentType) 
Allows generating explicitly an AGEC 
void disconnectionReq(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang. String mimeContentType) 
Allows closing a session, 
void disconnectionSsp(SipEndUser user, int connectionld) 

Allows replying to an incoming request to close a session, 
void optionsReq(SipEndUser user, int connectionld, java.lang. String target, 
java.io.Serializable body, java.lang. String mimeContentType) 
Allows sending an OPTIONS, 
void optionsRsp(SipEndUser user, int connectionld, java.io.Serializable body, 
java.lang. String mimeContentType) 

Allows replying to an incoming OPTIONS, 
void messageReq{SipEndUser user, int connectionld, java.lang. String target, 
java.io.Serializable body, java.lang.String mimeContentType) 
Allows sending a MESSAGE, 
void messageRsp(SipEndUser user, int connectionld, java.io.Serializable body, 
java.lang.String mimeContentType) 

Allows replying to an incoming MESSAGE, 
void provisionalAckReq(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 
Allows sending a PRACK. 
void provisionalAckRsp(SipEndllser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 

Allows replying to an incoming PRACK. 
void registerReq(SipEndUser user, SipRegistrationReq registration, java.io.Serializable body, 
java.lang.String bodytype) 

Allows registering the specified user at the given SIP Registrar, 
void reservationCoordReq{SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 
Allows sending an UPDATE, 
void reservationCoordRsp(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 

Allows replying to an incoming UPDATE, 
static void setUserAgentFactory(SipUserAgentFactory fac) 
Enforces' the use of a custom peer factory. 
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void connectionCfm(SipEndUser user, int connectionld r java Jang. String frorn, 
java.io.Serializable body, java.lang. String mimeContentType) 
Acknowledges a SIP session establishment 
void provisionalAckCfinfSipEndUser user, int connection^, Java Jang. String from, 
java.io.Serializable body, java.lang. String mimeContentType) 
Acknowledges a PRACK. 
void registerCfm(SipEndUser user, SipRegistrationCfm registration, int status, 
java.io.Seriaiizable body, java.lang. String mimeContentType) 
Actaowl^^ 



Tab. 13 



m ^ ^ ; ::'..-.j„-.' '" ■ i ..I . 

void ci^ecti^ user, int connectiontd, java.lang. String from; 

java.io.Serializable body, java.lang.String mimeContentType) 
Indicates an incoming request of SIP session establishment 
void provisionalAckInd(SipEndUser user, int connections, java.lang.String from, 
java.io.Serializable body, java.lang.String mimeContentType) 

Indicates an incoming PRACKL j ... 
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void connectionStatnsIndtSipEr^User user, in t co nnectionld inTtVoe 

Kiss; rsstssr--^ *~ 

. . _ ^dicates an incoming provisional response from the peer 
1Ml , „ Acknowledges a former request to close the session. 

a request from the peer to close the session. 

SS^SSSSS^J^' ^ co ™ ec *°" W ' iava..ang.String from. 
java.icLSerializable body. java.lang.String mimeContentType) 
Notifies the incoming of an OPTION'S 

VO ' d S^gSSSS^ T' 1* conne « j °*^ . java.lang.String from, 
vSST^f" °? y ' J ava - ,an 9.String mimeContentType) 
Notifies the incoming of a MESSAGE 

V ° ,?vl°fo? ni ^- P l n . dUser USer ' int connectionld. java.lang.String from 
java.io Senahzable body. java.lang.String mimeContentType^ 
. . Acknowledges a former request to send an OPTIONS 

"e^geCfiniSipEndUser user, int connectionld, . java.lang.String from 
java.,o Senahzable body, java.lang.String mimeContentType) ° ' 

wni . _ Acknowledges a a former request to send a MESSAGE. 

Acknowledges a former request to send an UPDATE 
Indicates an mconnnjr T m DA TE sent by the peer. 

***** ~.~».... ........ 
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SVOO 

void bindReq(SipEndUser user, SipRegistrarListener ssml) ~ ^ " ^ 

Binds the given user's event listener to the given SIP UA. 
void configareReq(SipManagementListener sml, SipConfigurationReq conf) 

Configures the given SIP UA. 
V °M optionsRsp(SipEndUser user, int connectionld, java.io.Serializable body, 
I ■ java.lang. String mimeContentType) ' j 

Acknowledges an OPTIONS, 
void messageRsp{SipEndUser user, int connection Id, java.io.Serializable body, 
I java.Iang.String mimeContentType) 

Acknowledges a MESSAGE, 
void registerRsp(SipEndUser user, int connectionld, SipRegistrationRsp registration, 
| Int status, java.io.Serializable body, java.Iang.String bodytype) 
j r ^""^SJj^ from SIP users. 
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void regi8terIhd(SipEndUser user, int connectionld, SipRegistrationTndT enis^ti^ 
java.,o.Serializab«e body, java.lang.String mimeContemTyJe) re9 ' Strat,on ' 
Indicates a request from the peer to make a registration. 
vo.d option S fad(Si P EndUser user, int connection^. java.lang.String from 
java-.o^erializable body. java.lang.String mimeContentType) 
Notifies the incoming of an OPTIONS 

V ° ld STSESSSlJK U " er ' T co "" eCtl ° n,d ' J«-.'«"0.8trinB from, 
java.io Senalizable body, java.lang.String mimeContentType) 
Notifies th e incoming of a MESSAGE. 
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Source State 



Triggering event 



Guard 
condition 



Action 



Target 
state 



Root . ReNegOf f erer . 
WaitPrackCfm 



connectionStat us Ind 



Status >= 
300 



abortlnd 



Root. 

Session 
Esta- 
blished 



Root . ReNegOf f erer . 
WaitReservCompl 



Timer Til expires 



failurelnd 



Root . 

WaitTo 

Clear 



Root . ReNegOf f erer . 
WaitCoordCfm 



connectionStatusInd 



Status >= 
300 



abortlnd 



Root . ReNegOf f erer . 
WaitRinging 



connectionStatusInd 



Status >= 
300 



failurelnd 



Root. 
Session 
Esta- 
blished 



Root. 

WaitTo 

Clear 



Root . ReNegOf f erer . 
WaitFinalProvAckCfm 



connectionStatusInd 



Status 
300 



abortlnd 



Root . 
Session 
Esta- 
blished 



Root . ReNegOf f erer . 
Wai t ConnectionC fm 



conn e c ti onS tatuslnd 



Status 
300 



abortlnd 



Root. 
Session 
Esta- 
blished 



Root . ReNegOf f erer . 
WaitContract 
Adjusted 
Root.NegAnswerer 



Timer T12 expires 



failurelnd 



Root . 

WaitTo 

Clear 



negotiationReq 



abortlnd 



Root . 
Neg 
Answe- 
rer 



reNegotiat ionRe <j 



abortlnd 



Root . 
Neg 
Answe- 
rer 



Timer T105 expirres 



failurelnd 



Root. 

WaitTo 

Clear 



Root . NegAnswerer . 
WaitAnswer 



Timer T13 expires 



failurelnd 



Root. 

WaitTo 

Clear 



Root . NegAnswerer . 
WaitCounterOf fer 



Stco 



Source stat*p 




condition 




Target 
state 


Root • NegOf f erer . 
WaitReservCompl 


Timer T7 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root - NegOf f erer . 
WaitCoordCfm 


connect! onS tat us Ind 


Status >= 
300 


failurelnd 


Root. 

WaitTo 

Clear 


Root . NegOf f erer . 
WaitRinging 


connectionStatusInd 


Status >= 
300 


failurelnd 


Root . ~~ 

WaitTo 

Clear 


Root . NegOf f erer . 
WaitFinalProvAckCfim 


connectionStatusXnd 


Status >= 
300 


failurelnd 


Root. 

WaitTo 

Clear 


Root . NegOf f erer . 
WaitConnectionCfm 


connectionStatusInd 


Status >= 
300 


failurelnd 


Root* 

WaitTo 

Clear 


Root . NegOf fere r. 

WaitContract 

Adjusted 


Timer T8 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root . ReNegOf f erer 


Timer T104 expires 




failurelnd 


Root* 

WaitTo 

Clear 


Root . ReNegOf f erer • 
Wa i t ReNeg Re q 


conne ctionS ta tu s Ind 


Status >= 
300 


abortlnd 


Root. . 
Session 
Esta- 
blished 




Timer T9 expires 




_ ResvMtx. 

signal 

abortlnd 


Root. 
Idle 


Root . ReNegOf f erer . 
WaitTryinglnd 


connectionStatusInd 


Status >= 
300 


abortlnd 


Root. 
Session 
Esta- 
blished 


Root . ReNegOf f erer . 
Wai t Progres s Ind 


connectionStatusInd 


Status >= 
300 


abortlnd 


Root. 
Session 
Esta- 
blished 


Root • ReNegOf f erer . 
WaitNegStatusRsp 


Timer T10 expires 




failurelnd 


Root. 

WaitTo 

Clear 



gZco 



Source State 


Triggering event 


Guard 
condition 


Action 


Target 
state 


Root. Idle 


disconnecfcionCfni 




releaseCfm 


Root* 
Idle 




releaseRsp 




disconnection 


Root, 
lux s 


Root.WaitRenewLease 
Rsp 


Timer T2 expires 




failurelnd 


Root. 

WaxtTo 

Clear 


Root - Wai tRenewLease 

CflTI 


connections tatuslnd 


Status >= 
300 


abortlnd 


Root. 
Idle 




Timer T101 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root .WaitPreNegot 
Rsp 1 


Timer Tl expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root . WaitPreNegot 
Cfra 


connectionStattLsInd 


Status >= 
300 


abortlnd 


Root. 
Idle 




Timer T102 expires 




failurelnd 


Root. [ 

WaitTo 

Clear 


Root . NegOf f erer 


Timer T103 expi res 




failurelnd 


Root. 

WaitToC 

lear 


Root . ReNegOf f erer - 
WaltNegReq 


connections tatu. slnd 


Status >= 
300 


abortlnd 


Root. 
Session 
Esta- 
blished 




Timer T5 expires 


j 


_ResvMtx. sign 
al abortlnd 


Root. 
Idle 


Root . NegOf f erer . 
WaitTryinglnd 


conne c t i onS t a tu. s Ind 


Status >= 
300 


abortlnd 


Root. 
Idle 


Root . NegOf f erer . 
WaitProgressInd 


connections tatu. s Ind 


Status >= 
■arm 


abortlnd 


Root. 
Idle 


Root . NegOf f erer . 
WaitNegStatusRsp 


Timer T6 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root . NegOf f erer - 
WaitPrackCfm 


connectionstatuslnd 


Status >= 
300 


failurelnd 


Root. 

WaitTo 

Clear 



Triggering event 



Root . NegAnswerer J 
WaitNegStatusRsp 



Guard 
condition 



Timer 114 expires 



Root . NegAnswerer"! 
WaitFi na ip rovAck 

Root . NegAnswerer 7 
WaitFinalAnswer 



Timer T15 expires' 



Root. NegAnswerer." 
HoldOnAnswer 

Root.NegAnswererT 
WaitCon nectionCfm 
Root .NegAnswerer ." 



RooL . ReNegAnswerer." 
WaitAnswer 



RooL . ReNegAnswerer" 
WaitCounterOffer 
«ooc . ReNegAnswerer^ 
WaitNegStatusRsp 

kooc . ReNegAnswerer". 
WaitFinalProvAck 



Root . ReNegAnswerer: 
WaitFinalAnswer 



Action 



failure ind 



failurelnd 



— — — ■ ^ • 

WaitForCoordDone. 
WaitLocalCoord 
Root - NegAnswerer T 
Wai tForCoordDone . 
WaitRemoteCoord 
Root . NegAnswerer". 
WaitForcbordDone . 
LocalTok enAchleved 
Root . NegAnswerer, — 
WaitForCoordDone. 
RemoteToke nAchieved 
Koot . ReNegAnswerer" 



Timer T19 expires 



failurelnd . 



failurelnd 



xuner T16 expires 



Timer T17 expires 



Timer T18 expires 



failurelnd 



failurelnd 



failurelnd 



Target" 
state 



Root. 

WaitTo 

Clear 



Hoot. 

WaitTo 

Clear 



Root. 

WaitTo 

Clear 

Root. 

WaitTo 

Clear 



Root. 

WaitTo 

Clear 

Root. 

WaitTo 

Clear 



Root. 

WaitTo 

Clear 



Root. 

WaitTo 

Clear 



I Source State 




Guard 
condition 


Tk "i rtn 
/Av_» UXUI1 


Target 
state 


1 Root - T5p»"M£»rrAn cup «-o «•> 

J HoldOnAnswer 










1 Root. ReNegAnswerer. 
i Wdj. Luonnec tioncini 










Root. ReNegAnswerer. 
1 WaitForCoordDone. 
I WaitLocalCoord 


Timer T21 expires 




failurelnd 


Root. 

WaitTo 

Clear 


j Root, ReNegAnswerer. 
I WaitForCoordDone. 
J WaitRemoteCoord 


Timer T22 expires 




failurelnd 


Root. 

WaitTo 

Clear 


j Root. ReNegAnswerer. 
1 WaitForCoordDone . 
1 LocalTokenAchieved 










J Root. ReNegAnswerer. 
j WaitForCoordDone . 
j RemoteTokenAchieved 


... •.. 








1 Root; Session 
1 Established 










I Root.WaitReleaseRsp 


di s connectionCfrfl 


• 


releaseCfm 


Root. 
Wait 
Release 
Rsp 




Timer T3 expires 




releaseReq 


Root. 
Wait | 
Discon- 
nection 
Cfm 


Root . WaitToClear 


Timer T4 expires 




releaseReq 


Root. 

Wait 
Discon- 
nection 
Cfm 


Root.WaitDisconnect 
ionCfm 


releaseRsp 




disconnection 


Root. 
Waxt 
Discon- 
nection 
Cfm 
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STao 



J Name 


s | Description 


Default""" 


Tl 


J Waiting pre-negotiation response from E2ENP UA API 
Service User 


TBD 


T2 
I T3 


Waiting lease renew response from E2ENP UA API 
Service User 


TBD 




Waxtmg release response from E2ENP UA API Service" 
1 User 


TBD 


T4 


Waiting release request from E2ENP UA API Service " 
User, after .the E2ENP UA has generated a failure 
indication or a congestion indication to the 
I Service User. 


TBD 


T5 


1 Waiting negotiation request from E2ENP UA API 
Service User after having booked the resource 
reservation mutex at the offerer side 


TBD 


1 * 


Waiting negotiation status response with counter- 
offer, from E2ENP UA API Service User at the 
offerer side 


TBD 


1 1 


waiting start reservation response from E2ENP UA 
API Service User at the offerer side 


TBD 


T8 


waiting negotiation status response from E2ENP UA 
service User to handle contract adjustment at 
the offerer side 


TBD 


T9 


Waiting re negotiation request from E2ENP UA API 
Service User after having booked the resource 
reservation mutex at the offerer side 


TBD 


T10 
Til | 
[T12 T 


Waiting re negotiation status response with 
counter-offer, from E2ENP UA API Service User at 
the offerer side 

Waiting start reservation response from E2ENP UA 
API Service User, during re -negotiation at the 
offerer side 

Waiting re-negotiation status response from E2ENP 
UA API Service User to handle contract adjustment 
at the offerer side 


TBD 

TBD ~ 
~TBD 



Name Description 



T13 



Waiting negotiation status response with answer 
from E2ENP UA API Service User at the answerer 
side 



Default 
Value 



TBD 



T14 



T15 



T16 



T17 



T18 



T19 



Waiting negotiation status response with TBD 
counteroffer from E2ENP UA. API Service User at the 
answerer side 

Waiting negotiation response from E2ENP UA API TTBD" 
Service User at the answerer side 

Waiting re-negotiation status response with answer f tbd~ 
from E2ENP UA API Service User at the answerer 
side 

Waiting re-negotiation status response with | TBD 

counteroffer from E2ENP UA. API Service User at the 
answerer side 

Waiting re-negotiation response from E2ENP UA API TBD 
Service User at the answerer side 

Waiting start reservation response from E2ENP UA ) tbd 
I API Service User at the offerer side during 
negotiations 



Waiting negotiation response from E2ENP UA API 
Service User side for handling adjusted contracts 
during negotiations 



TBD 



T22 



Waiting start reservation response from E2ENP UA 
API Service User at the offerer side during re- 
negotiations 

Waiting negotiation response from E2ENP UA API 
Service User side for handling adjusted contracts 
during re-negotiations 



TBD 



TBD 



T101 I Waiting OPTIONS confirmation from SIP API for 

handling lease renewal primitive 
T102 [Waiting MESSAGE confirmation from SIP UA for" 
handling pre-negotiation primitive 



TBD 



TBD 



Name 


Description 


Default. 
Value 


"T103 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as offerer in a 
necrotiation tirocess 




T104 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as answerer in a 


TBD 


T105 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as offerer in a re- 
neciotiation Drocess 


TBD 


T106 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as answerer in a re- 
negotiation process 


TBD 
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